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Foreword 



This Technical Specification (TS) has been produced by ETSI Technical Committee Digital Enhanced Cordless 
Telecommunications (DECT). 

The present document is based on EN 300 175 parts 1 to 8 ([1], [2], [3], [4], [5], [6], [7] and [8]) and EN 300 444 [11]. 
General attachment requirements and speech attachment requirements are based on EN 301 406 [10] (replacing 
TBR 006 [i.2]) and EN 300 176-2 [9] (previously covered by TBR 010 [i.3]). Further details of the DECT system may 
be found in TR 101 178 [i.l]. 

The present document has been developed in accordance to the rules of documenting a profile specification as described 
inISO/IEC9646-6[i.l2]. 

The information in the present document is believed to be correct at the time of publication. However, DECT 
standardization is a rapidly changing area, and it is possible that some of the information contained in the present 
document may become outdated or incomplete within relatively short time-scales. 

The present document is part 5 of a multi-part deliverable covering the New Generation DECT as identified below: 

Part 1: "Wideband speech" [17]; 

Part 2: "Support of transparent IP packet data" [i.4]; 

Part 3: "Extended wideband speech services" [18]; 

Part 4: "Light Data Services: Software Update Over The Air (SUOTA), content downloading and HTTP based 
applications" [i.5]; 

Part 5: "Additional feature set nr. 1 for extended wideband speech services". 
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1 Scope 

The present document specifies a set of functionalities of the New Generation DECT. 

The New Generation DECT provides the following basic new functionalities: 

Wideband speech service (part 1). 

Packet-mode data service supporting Internet Protocol with efficient spectrum usage and high data rates 
(part 2). 

Extended wideband speech services (part 3). 

Light Data Services: Software Update Over The Air (SUOTA), Content Downloading and HTTP based 
applications (part 4). 

Additional feature set nr. 1 for extended wideband speech services (part 5). 

All New Generation DECT devices will offer at least one or several of these services. 

The present document describes the part 5: Additional feature set nr. 1 for extended wideband speech services. 

• For the description of the wideband speech service, see TS 102 527-1 [17]. 

• For the description of the support of transparent IP packet data, see TS 102 527-2 [i.4]. 

• For the description of the Extended wideband speech services, see TS 102 527-3 [18]. 

• For the description of the Light Data Services: Software Update Over The Air (SUOTA), Content 
Downloading and HTTP based applications, see TS 102 527-4 [i.5]. 

Part 5 ("Additional feature set nr. 1 for extended wideband speech services") is defined as an extension of part 3 
("Extended wideband speech services" [18]) which is itself an extension of part 1 ("Wideband speech service" [17]). 
Consequently, this means that all devices compliant to the present document will also implement at least all mandatory 
features and may implement the optional features defined in part 3 and part 1 . In addition to that, the present document 
defines additional mandatory or optional features. 

Part 1, and therefore also part 3 and part 5, are defined as extensions of the "Generic Access Profile (GAP)" [11]. All 
DECT devices offering Wideband speech services (part 1, or part 1 plus part 3, or part 1 plus part 3 plus part 5) are also 
compliant with the "Generic Access Profile (GAP)" [11], and offer the DECT standard 32 kbit/s voice service according 
to GAP [11]. 

All DECT devices claiming to be compliant with this Application Profile will offer at least the basic services defined as 
mandatory. In addition to that, optional features can be implemented to offer additional DECT services. 

The aim of the present document is to guarantee a sufficient level of interoperability and to provide an easy route for 
development of DECT wideband speech applications, with the features of the present document being a common 
fall-back option available in all compliant to this profile equipment. 

The present document is defined as an extension of TS 102 527-3 [18] so the numbering and order of figures and tables 
in the present document is aligned with the corresponding numbering and order of figures and tables in 
TS 102 527-3 [18]. 
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specification; Part 2: Audio and speech". 

[10] ETSI EN 301 406: "Digital Enhanced Cordless Telecommunications (DECT); Harmonized EN for 

Digital Enhanced Cordless Telecommunications (DECT) covering the essential requirements 
under article 3.2 of the R&TTE Directive; Generic radio". 

[II] ETSI EN 300 444: "Digital Enhanced Cordless Telecommunications (DECT); Generic Access 
Profile (GAP)". 

[12] Recommendation ITU-T G.726 (1990): "40, 32, 24, 16 kbit/s Adaptive Differential Pulse Code 

Modulation (ADPCM) ". 

[13] Recommendation ITU-T G.71 1 (1988): "Pulse code modulation (PCM) of voice frequencies". 

[14] Recommendation ITU-T G.722 (1988): "7 kHz audio-coding within 64 kbit/s". 

[15] Recommendation ITU-T G.729. 1 (2006): "G.729-based Embedded Variable bit-rate coder: 

An 8-32 kbit/s scalable wideband coder bitstream interoperable with G.729". 

[16] ISO/lEC JTC1/SC29AVG1 1 (MPEG): International Standard ISO/IEC 14496-3:2005: 

"Information Technology - Coding of audio-visual objects - Part 3: Audio". 
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[17] ETSI TS 102 527-1: "Digital Enhanced Cordless Telecommunications (DECT); New Generation 

DECT; Part 1: Wideband Speech". 

[18] ETSI TS 102 527-3: "Digital Enhanced Cordless Telecommunications (DECT); New Generation 

DECT; Part 3: Extended Wideband Speech Services". 

[19] ETSI TS 123 038 (VI 1.0.0) (20 12- 10): "Digital cellular telecommunications system 

(Phase 2H-);Universal Mobile Telecommunications System (UMTS); LTE;Alphabets and 
language-specific information (3GPP TS 23.038 version 11.0.0 Release 11)". 

2.2 Informative references 

The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 

[i.l] ETSI TR 101 178: "Digital Enhanced Cordless Telecommunications (DECT); A high Level Guide 

to the DECT Standardization". 

[i.2] ETSI TBR 006: "Digital Enhanced Cordless Telecommunications (DECT); General terminal 

attachment requirements". 

[i.3] ETSI TBR 010: "Digital Enhanced Cordless Telecommunications (DECT); General terminal 

attachment requirements: Telephony applications". 

[i.4] ETSI TS 102 527-2: "Digital Enhanced Cordless Telecommunications (DECT); New Generation 

DECT; Part 2: Support of transparent IP packet data". 

[i.5] ETSI TS 102 527-4: "Digital Enhanced Cordless Telecommunications (DECT); New Generation 

DECT; Part 4: Light Data Services; Software Update Over The Air (SUOTA), content 
downloading and HTTP based applications". 

[i.6] Recommendation ITU-T P. 31 1 (2005): "Transmission characteristics for wideband (150-7000 Hz) 

digital handset telephones". 

[i.7] Recommendation ITU-T G.729: "Coding of speech at 8 kbit/s using conjugate structure algebraic- 

code-excited linear prediction (CS-ACELP)". 

[i.8] Recommendation ITU-T Q.23 (1988): "Technical features of push-button telephone sets". 

[i.9] Recommendation ITU-T Q.24 (1988): " Multifrequency push-button signal reception". 

[i.lO] Recommendation ITU-T E.180: "Technical characteristics of tones for the telephone service". 

[i.l 1] Recommendation ITU-T E.180- Supplement 2 (1994): "Various tones used in national networks". 

[i.l2] ISO/IEC 9646-6: "Information technology - Open Systems Interconnection - Conformance testing 

methodology and framework - Part 6: Protocol profile test specification". 

[i.l 3] ISO/IEC 9646-7: "Information technology - Open Systems Interconnection - Conformance testing 

methodology and framework - Part 7: Implementation Conformance Statements". 

[i.l4] ETSI TS 123 040 (VI 1.3.0) (2012-10): "Digital cellular telecommunications system 

(Phase 2H-);Universal Mobile Telecommunications System (UMTS);Technical realization of the 
Short Message Service (SMS) (3GPP TS 23.040 version 1 1.3.0 Release 1 1)". 

[i.l5] ETSI ES 201 912 (Vl.2.1) (2004-08): "Access and Terminals (AT);Short Message Service (SMS) 

for PSTN/ISDN; Short Message Communication between a fixed network Short Message 
Terminal Equipment and a Short Message Service Centre". 
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3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in EN 300 444 [11] and the following apply: 

attached to a line: PP is "attached to a line" if its associated bit is set in the "Handset bitmap" in the "Attached 
handsets" field of the "Line Settings List" entry for that line 

NOTE: A PP that is attached to a line can send and receive calls on that line. 

call status: part of the call information sent from FP to PP about the FP call state toward the peer party 

double call with in-band signalling (line): legacy line on which second calls -incoming or outgoing- are handled using 
signalling "in-band" 

FP-managed line selection: mode for an outgoing external call, in which the PP does not indicate the line to be used to 
the FP and the FP chooses the line where the call is placed 

Headset PP (HPP): headset PP is a wireless headset telephone using the DECT air interface 

NOTE: A HPP usually has only one speaker and one microphone combined with a limited set of keys (e.g. call 
button, volume plus, and volume minus). Headsets provide the equivalent functionality of a PP with 
hands -free operation. 

late release: sending of a "CS idle" call status by the FP for a call that has been released a long time before in the 
network. 

NOTE: See clause 7.4.3.10.3.1. 

line: logical channel, separately accessible from the external world through a dedicated external directory entry 
(e.g. telephone number, uri, etc.) 

NOTE: These lines may be of various types, for example: PSTN, VoIP or ISDN lines. 

multiple call line: line supporting several simultaneous (external) calls 

NOTE: An example of multiple call line is a VoIP line used with the SIP protocol. 

multiple-call mode: configuration mode of a multiple call line from a DECT system point of view, enabling several 
simultaneous incoming or outgoing calls on different PPs (i.e. this possibility is not disabled by configuration) 

new generation DECT: further development of the DECT standard introducing wideband speech, improved data 
services, new slot types and other technical enhancements 

none: a special line identifier value (called "None") is defined in clause 7.7.56 of EN 300 175-5 [5] and is used to 
indicate that the line id for the external call is not yet known 

NOTE: It is used for FP managed line selection (clauses 7.4.3.5.1 and 7.4.5.2.4) and, as a special case, for call 
intrusion (clause 7.4.3.8). 

off-hook CLIP: ability of a network to send CLIP information for a waiting call (also known as "CLIP on call waiting" 
or "CLIP phase 11") 

single-call mode: configuration mode of a multiple call line from a DECT system point of view, in which the 
possibility of making several fully parallel call is (temporarily) disabled 

NOTE: This mode may be useful for a user alone in the home. This mode does not prevent several simultaneous 
calls on the same PP. A line which is not "multiple call" (for instance a PSTN line only enabling double 
calls) is also said to be in "single call" mode. 

super-wideband speech: voice service with enhanced quality compared to ADPCM G.726 and allowing the 
transmission of a maximum vocal frequency of at least 14 kHz 
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wideband speech: voice service with enhanced quality compared to ADPCM G.726 and allowing the transmission of a 
vocal frequency range of at least 150 Hz to 7 kHz, and fulfilling, at least, the audio performance requirements described 
in the Recommendation ITU-T P.31 1 [i.6] 



3.2 Symbols 



For the purposes of the present document, the following symbols apply: 



M 
O 
I 
C 

N/A 



mandatory to support (provision mandatory, process mandatory) 

optional to support (provision optional, process mandatory) 

out-of-scope (provision optional, process optional) not subject for testing 

conditional to support (process mandatory) 

not applicable (in the given context the specification makes it impossible to use this capability) 



Provision mandatory, process mandatory means that the indicated feature service or procedure is to be implemented as 
described in the present document, and may be subject to testing. 

Provision optional, process mandatory means that the indicated feature, service or procedure may be implemented, and 
if implemented, the feature, service or procedure is to be implemented as described in the present document, and may 

be subject to testing. 

NOTE: The used notation is based on the notation proposed in ISO/IEC 9646-7 i.l3. 

3.3 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AAC Advanced Audio Coding (MPEG) 

AAC-LD MPEG-4 Low Delay Audio Coder 

AC Authentication Code 

ADPCM Adaptive Differential Pulse Code Modulation 

AES Advanced Encryption Standard 

AI Air Interface 

API Application Program Interface 

ARI Access Rights Identity 

ARQ Automatic Repeat reQuest 

ASCII American Standard Code for Information Interchange 

BCD Binary Coded Decimal 

BTPC Base manual Transmit Power Control 

CC Call Control 

CFB Call Forwarding on Busy 

CFNA Call Forwarding on No Answer 

CFU Call Forwarding Unconditional 

CI Common Interface 

CLIP Calling Line Identification Presentation 

CLIR Calling Line Identity Restriction 

CNIP Calling Name Identification Presentation 

CRC Cyclic Redundancy Check 

CS Call Status 

DCIBS Double Call with In-Band SignalHng 

DECT Digital Enhanced Cordless Telecommunications 

DHCP Dynamic Host Configuration Protocol 

DLC Data Link Control 

DNS Domain Name System 

DSAA DECT Standard Authentication Algorithm 

DSAA2 DECT Standard Authentication Algorithm #2 

DSC DECT Standard Cipher (algorithm) 

DSC2 DECT Standard Cipher (algorithm) #2 

DTAM Digital Telephone Answering Machine 

DTMF Dual Tone Multi-Frequency 

ECN Exchanged Channel Number 
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ER Error Resilient (MPEG) 

EEC Forward Error Correction 

FP Fixed Part 

FT Fixed radio Termination 

GAP Generic Access Profile 

GFSK Gaussian Frequency-Shift Keying 

GMT Greenwich Mean Time 

HATS Head And Torso Simulator 

HPP Headset Portable Part 

HTTP HyperText Transfer Protocol 

lA Implementation Alternative 

IE Information Element 

IP Internet Protocol 

IPUI International Portable User Identity 

ISDN Integrated Services Digital Network 

IWU InterWorking Unit 

LA Location Area 

LAN Local Area Network 

LAPC Link Access Protocol for the Control plane 

LD Low Delay (MPEG) 

Li A List Access 

LLME Lower Layer Management Entity 

LU Link Access Protocol User 

MAC Medium Access Control 

MD Manufacturer Defined 

MM Mobility Management 

MMI Man Machine Interface 

MPEG Moving Picture Experts Group 

NA Not Applicable 

NG New Generation 

NG-DECT New Generation DECT 

NWK NetWorK 

P Public (environment) 

PABX Private Automatic Branch Exchange 

PARK Portable Access Rights Key 

PCM Pulse Code Modulation 

PHL PHysical Layer 

PIN Personal Identification Number 

PLC Packet Loss Concealment 

PP Portable Part 

PSTN Public Switched Telephone Network 

PT Portable radio Termination 

R/B Residential/Business (environment) 

REP Radio Fixed Part 

RFPI Radio Fixed Part Identity 

S/T ISDN S/T Interface 

SARI Secondary Access Rights Identity 

SC Speech Coding 

SIP Session Initiation Protocol 

SMS Short Message Service 

SMSC SMS Centre 

TCLw weighted Telephone Coupling Loss 

TPUI Temporary Portable User Identity 

TRUP TRansparent UnProtected service 

U ISDN U-Interface 

UAK User Authentication Key 

UCS Universal Character Set 

UMT Universal Mean Time 

UNF UNprotected Framed service 

UPI User Personal Identity 

UTF UCS Transformation Format 

VoIP Voice over IP 
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WAN 
WB 



Wide Area Network 
WideBand 



4 Description of Services 

4.1 Additional feature set nr.1 for extended wideband speech 
services 

The present document is defined as an extension of New Generation DECT; part 3: extended wideband speech services 
(TS 102 527-3 [18]). All devices compliant with the present document shall implement all mandatory features and may 
implement all optional features defined in TS 102 527-3 [18]. In addition to that, the present document defines 
additional features and procedures, or upgrades the support status of features and procedures defined in 
TS 102 527-3 [18]. 

See TS 102 527-3 [18], for description of the extended wideband speech services. 

The present document is also defined as an extension of New Generation DECT; part 1 : wideband speech 
(TS 102 527-1 [17]). All devices compliant with the present document shall implement wideband (150 Hz to 7 kHz) 
audio with 16 kHz frequency sampling, and shall implement, at least, the speech coding format according to 
Recommendation ITU-T G.722 [14]. In addition to that, other wideband and superwideband audio codecs, providing 
even better audio quality, may be implemented. 

See TS 102 527-1 [17], clause 4.1 for description about wideband speech. 



4.1 .1 Back-compatibility with GAP 

The present document is defined as a backcompatible extension of the Generic Access Profile (GAP), EN 300 444 [11]. 
All devices compliant with the present document shall be interoperable with equipment compliant with Generic Access 
Profile (GAP) [11] and shall implement ADPCM narrowband speech service according to Recommendation ITU-T 
G.726 [12], with automatic detection of the capabilities of the other peer. 

4.1 .2 Back-compatibility with New Generation DECT; Part 1 : wideband 
speech 

The present document is defined as a backcompatible extension of the New Generation DECT; Part 1: wideband 
speech, TS 102 527-1 [17]. All devices compliant with the present document shall be interoperable with equipment 
compliant with New Generation DECT; Part 1: wideband speech, TS 102 527-1 [17]. They shall implement the 
procedures described in TS 102 527-1 [17] and shall implement the 7 kHz wideband speech codec according to 
Recommendation ITU-T G.722 [14], with automatic detection of the capabilities of the other peer. They may also 
implement the optional codecs described in TS 102 527-1 [17]. 

4.1 .3 Back-compatibility with New Generation DECT; Part 3: extended 
wideband speech services 

The present document is defined as a backcompatible extension of the New Generation DECT; Part 3: extended 
wideband speech services, TS 102 527-3 [18]. All devices compliant with the present document shall be interoperable 
with equipment compliant with TS 102 527-3 [18]. They shall implement all mandatory procedures described in 
TS 102 527-3 [18] and may implement the optional procedures. 

The following editorial conventions regarding feature or service descriptions (i.e. from clause 7.4 on) are used in the 
present document: 

New clauses NOT existing in TS 102 527-3 [18] use free clause numbers (i.e. not used in TS 102 527-3 [18]). 



£75/ 



17 



ETSI TS 102 527-5 VI. 1.1 (2013-04) 



Clauses already existing in TS 102 527-3 [18] keep their original clause number in the present document: 

If the clause has not been updated for the present document, only its title is repeated here, and its content is 
replaced with a statement that the clause with same number in TS 102 527-3 [18] applies. 

NOTE: As an exception to this rule, subclauses of such clauses (also unchanged by definition) do not appear at all 
in the present document. 

If the clause has been updated for the present document, then sibling clauses of that clause are always present 
(whether updated or not). For the updated clause, one of the following cases occurs: 

if the change is an addition of text at the end of the original clause, only the additional text is given in the 
present document, with an explanatory sentence at clause start; 

if the change is at any other place in the clause, or if it is not an addition (e.g. a modification or a 
removal), or if there are multiple changes in the clause, then the whole new text of the clause is given. 
However, in order to help the reader already aware of the original clause wording, tags are added to the 
new text at all spots where a change occurred. 

Tag format. The following rules are used for the tag format (see also the following table). 

An enclosing pair of tags is used for each change: the change is enclosed between a begin tag and an end tag. 

The begin tags contains the type of change: either a 'modification', a 'deletion', or an 'addition' 

At some places a single tag pair is used for several changes (in that case a 'modification' tag pair is used). 



Tag pair type 


Tag pair format 


Tag pair used for text addition 


«Text changed from TS 102 527-3 [18] (addition) 

...the added text... 
End of cliange» 


Tag pair used for text modification 
(content may include some 
unclianged text) 


«Text changed from TS 102 527-3 [18] (modification) 

...modified text... 
<= End of cfiange» 


Tag pair used for text modification 
(example with some explanative 
text following tag type) 


«Text changed from TS 102 527-3 [18] (modification, field "..." added in 
table) 

...modified text... 
End of change» 


Tag pair used for text deletion 
Such tags have no content at all 


«Text changed from TS 102 527-3 [18] (deletion) 
End of change» 



4.2 Additional features for extended wideband speech services 
defined in the present document 

The following additional services are provided by the present document, compared to TS 102 527-3 [18]: 

• "Digital Telephone Answering Machine" (DTAM) feature. 

• "Short Message Service" (SMS) feature. 

• Enhanced 3-party conference call. 

• Enhanced intrusion call with on/off setting. 

• Enhanced CLIR with on/off setting. 

• Mandatory "Date and time recovery" procedure (already defined but optional in TS 102 527-3 [18]). 

• Mandatory "All Calls List" on FP side (already defined but optional in TS 102 527-3 [18]). 

• "Contact number and name matching on outgoing call" procedure. 

• "Contact number and name matching on incoming call" procedure. 
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"Line and diagnostic information" feature. 



• Green feature 1: "Base manual transmit power control" feature; (procedure content to be defined in a further 
revision of the present document). 

• Green feature 2: "Handset adaptive transmit power control" feature; (procedure content to be defined in a 
further revision of the present document). 

The new extended services, take in to account the additional scenarios possible in DECT systems connected to the 
network via VoIP interfaces. 



5 Service and feature definitions 

5.1 New Generation DECT Speech Services 

For the purposes of the present document, the definitions of TS 102 527-1 [17], clause 5.1 shall apply. 

5.2 Network (NWK) features 

For the purposes of the present document, all definitions of TS 102 527-3 [18], clause 5.2, TS 102 527-1 [17], 
clause 5.2 and EN 300 444 [11], clause 4.1, plus the following shall apply: 

Line and diagnostic information [NG1.N.23]: Ability for a DECT system to inform the user about the status of the 
system. 

Short Message Service [NG1.N.24]: Ability to send and receive SMS messages from a handset. 

Digital Telephone Answering Machine (DTAM) [NG1.N.25]: Ability for a DECT system to provide access to one or 
more digital telephone answering machine(s). 

DTAM Screening [NG1.N.26]: Ability for a DECT system and a DTAM to allow listening of messages when being 
recorded by the remote party. 

5.3 Data Link Control (DLC) service definitions 

For the purposes of the present document, all definitions of TS 102 527-1 [17], clause 5.3 and EN 300 444 [11], 
clause 5.1 shall apply. 

5.4 IVIedium Access Control (MAC) service definitions 

For the purposes of the present document, all definitions of TS 102 527-3 [18], clause 5.4, TS 102 527-1 [17], 
clause 5.4 and EN 300 444 [11], clause 5.2, shall apply. 

5.5 Physical Layer (PHL) service definitions 

For the purposes of the present document, all definitions of TS 102 527-1 [17], clause 5.5 shall apply. 

5.6 Speech coding and audio feature definitions 

For the purposes of the present document, all definitions of TS 102 527-1 [17], clause 5.6 shall apply. 
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5.7 Application features 



For the purposes of the present document, all definitions of TS 102 527-3 [18], clause 5.7 and EN 300 444 [11], 
clause 4.3 plus the following shall apply. 

Base manual transmit power control [NG1.A.4]: abihty to enter low transmit power state on the FP. 

Handset adaptive transmit power control [NG1.A.5]: abiUty to enable adaptive transmit power control on the PP. 



Inter-operability requirements 



6.1 General 

The tables listed in this clause define the status of all protocol elements (i.e. features, services, and procedures) which 
can be: mandatory, optional, conditional under the provision of another protocol element, outside the scope of the 
present document, or not applicable. The status is identified by the status column designations defined in clause 3.2, and 
is described separately for FT and PT. In the case of FT, the status can be different for products intended for the 
Residential/Business (R/B) market or for the Public market segment. 

Any optional elements chosen for implementation shall be implemented according to the procedures described in the 
present document. 

Protocol elements defined as mandatory, optional or conditional in this clause are further defined in the referenced 
DECT specification, or, if needed, in clause 7 of the present document. 

6.1 .1 Editorial conventions 

All New Generation DECT voice specifications are defined as backcompatible enhancements of EN 300 444 [11] 
(Generic Access Profile (GAP)). All procedures not specific of the New Generation DECT, are referenced to their 
original description in EN 300 444 [11] (GAP). 

New Generation DECT part 5 (the present document) is also defined as backcompatible enhancements of 
TS 102 527-1 (NG-DECT part 1) [17] and TS 102 527-3 (NG-DECT part 3) [18]. All procedures reused without 
modification from these two specifications are referenced to their original description in either TS 102 527-1 
(NG-DECT part 1) [17] or TS 102 527-3 (NG-DECT part 3) [18]. However, if any modification is required when the 
procedures are applied to the present document, they are newly described in the present document. 

The following editorial conventions regarding status tables are used in the present document: 

• Feature and service status tables for New Generation DECT Part 5 devices are listed in full in the present 
document. 

• Feature (or service) to procedures mapping tables are only provided when there is a modification in the feature 
(or service) procedure composition or references. Only modified entries (feature or services) are listed. For all 
other entries, the mapping table of TS 102 527-3 [18] shall be used. Since TS 102 527-3 [18] follows the same 
editorial convention when features (or services) defined in GAP (EN 300 444 [11]) are used, this means that 
the user of the present document should potentially consult the mapping tables of these three documents to 
obtain the procedure composition of any service or feature. For convenience, an annex is provided (annex F) 
with the content of such tables at the time when the present document is released. However, this is only 
informative, and in case of errors or changes due to maintenance, the real content of the tables in 

EN 300 444 [1 1] (GAP) and TS 102 527-3 (NG-DECT part 3) [18] shall rule. 

There has not been any modification, compared to TS 102 527-3 (NG-DECT part 3) [18], in the following tables: 

• Speech services status (table 1) 

• Speech service to DECT features implementation mappings (table 2) 

• DLC services status (table 4) 
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• MAC services status (table 5) 

• PHL services status (table 6) 

• Speech Coding and audio features (table 7) 

• Application features status (table 8) 

NOTE: The MAC services table and Application features status table are changed by the Green feature. 
However, the tables are provided to in order to comply with ETSI editorial policy. 

6.1 .2 Radio and audio conformance requirements 

The requirements of EN 301 406 [10] and EN 300 176-2 [9] shall be met by all equipment conforming to the present 
document. 

6.2 New Generation DECT Speecii Services support status 

The following end-user services shall be supported by "New Generation DECT; Part 5: Additional feature set nr. 1 for 
extended wideband speech services" devices shall support the following end-user services. 

Table 1 : Speech service status 



Feature supported 




Status 1 


Item no. 


Name of Service 


Reference 


PT 


FT 1 


R/B 


P 


NG1.1 


Narrow band ADPCM G.726 32 kbit/s voice service 


5.1 [17] 


M 


M 


M 


NG1.2 


Narrow band PCM G.71 1 64 l<bit/s voice service 


5.1 [171 











NG1.3 


Wideband G.722 64 l<bit/s voice service 


5.1 [17] 


M 


M 


M 


NG1.4 


Wideband G.729.1 32 kbit/s voice service 


5.1 [17] 











NG1.5 


l\/lPEG-4 ER AAC-LD super wideband 64 kbit/s voice service 


5.1 [17] 











NG1.6 


l\/IPEG-4 ER AAC-LD wideband 32 kbit/s voice service 


5.1 [17] 












6.3 Services to DECT feature implementation mappings 

"New Generation DECT; Part 5: Additional feature set nr. 1 for extended wideband speech services" end user services 
shall be implemented using the DECT features and implementation alternatives defined in table 2. 

Table 2: Speech service to DECT features implementation mappings 



Service/DECT Feature mapping | 




Status 1 


Service 


lA 


DECT feature/service 


Reference 


PT 


FT 1 


R/B 


P 


NG1.1 Narrow band ADPCM 
G.726 32 kbit/s voice service 


1 




5.1 [17] 


M 


M 


M 


NG1.P.1 2 level GFSK modulation 


5.5 [17] 


M 


M 


M 


NG1.P.2 Physical Packet P32 


5.5 [17] 


M 


M 


M 


NG1.M.1 lN_minimum delay symmetric 
IVIAC service type 


5.4 [17] 


M 


M 


M 


GAPMA Basic Connections 


5.2 [11] 


M 


M 


M 


NG1 .M.4 Advanced Connections 


5.4 [17] 


C201 


C201 


C201 


NG1.D.1 DLC Service LU1 TRUP Class 
0/min delay 


5.3 [17] 


M 


M 


M 


NG1.D.5 DLC frame FU1 


5.3 [17] 


M 


M 


M 


NG1.SC.1 

Recommendation ITU-T G.726 [12] 

32 kbit/s ADPCM codec 


5.6 [17] 


M 


M 


M 
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Service/DECT Feature mapping 




Status 1 


Service 


lA 


DECT feature/service 


Reference 


PT 


FT 1 


R/B 


P 






NG1.SC.10 PP Audio type 1a (classic 
GAP liandset) 


5.6 [17] 


1 


N/A 


N/A 


NG1.SC.11 PP Audio type 1b 
(improved GAP handset) 


5.6 [17] 


1 


N/A 


N/A 


NG1.SC.12 PP Audio type 1c (HATS 
3,1 WHz handset) 


5.6 [17] 


G702 


N/A 


N/A 


NG1.SG.13 PP Audio type Id (HATS 
3,1 l<Hz improved handset) 


5.6 [17] 


G702 


N/A 


N/A 


NG1 .SG.1 7 PP Audio type 3a (HATS 
3,1 l<Hz handsfree) 


5.6 [17] 





N/A 


N/A 


NG1 .SG.1 8 PP Audio type 3b (HATS 
3,1 l<Hz improved handsfree) 


5.6 [17] 





N/A 


N/A 






NG1 .SG.23 FP Audio type 1 b (new 
ISDN 3,1 kHz) 


5.6 [17] 


N/A 


G706 


C706 


NG1 .SG.24 PP echo canceller for FP, 
narrowband 


5.6 [17] 


N/A 


G707 


C707 


NG1 .SG.25 PP echo supressor for FP, 
narrowband 


5.6 [17] 


N/A 


G707 


C707 


NG1 .SG.26 FP Audio type 2 (analog 
PSTN 3,1 kHz) 


5.6 [17] 


N/A 


G706 


C706 




NG1 .SG.27 FP Audio type 3 (VoIP 
3,1 kHz) 


5.6 [17] 


N/A 


G706 


C706 


NG1 .SG.32 FP Audio type 6a (internal 
call) 


5.6 [17] 


N/A 


M 


M 


NG1 .SG.33 FP Audio type 6b (internal 
conference) 


5.6 [17] 


N/A 








NG1 .SG.34 Adaptive volume control for 
FP 


5.6 [17] 


N/A 








NG1.2 Narrow band PCIM G.711 
64 l<bit/s voice service 


1 




5.1 [17] 











NG1.P.1 2 level GFSK modulation 


5.5 [17] 


M 


M 


M 


NG1.P.3 Physical Packet P64 


5.5 [17] 


M 


M 


M 


NG1.M.1 lN_minimum delay symmetric 
MAC service type 


5.4 [17] 


M 


M 


M 


NG1 MA Advanced Connections 


5.4 [17] 


M 


M 


M 


NG1.D.1 DLG Service LU1 TRUP Class 
0/min delay 


5.3 [17] 


M 


M 


M 


NG1.D.5 DLG frame FU1 


5.3 [17] 


M 


M 


M 


NG1.SC.2 

Recommendation ITU-T G.711 [13] 

64 kbit/s PGIVI codec 


5.6 [17] 


M 


M 


M 


NG1.SG.8 Detection of Fax/modem 
tone 


5.6 [17] 











NG1 .SC.9 Codec selection and 
switching 


5.6 [17] 


M 


M 


M 


NG1.SC.10 PP Audio type la (classic 
GAP handset) 


5.6 [17] 


1 


N/A 


N/A 


NG1.SG.11 PP Audio type lb 
(improved GAP handset) 


5.6 [17] 


1 


N/A 


N/A 


NG1.SG.12 PP Audio type 1c (HATS 
3,1 kHz handset) 


5.6 [17] 


G702 


N/A 


N/A 


NG1.SC.13 PP Audio type Id (HATS 
3,1 kHz improved handset) 


5.6 [17] 


G702 


N/A 


N/A 


NG1 .SC.1 7 PP Audio type 3a (HATS 
3,1 kHz handsfree) 


5.6 [17] 





N/A 


N/A 


NG1 .SG.1 8 PP Audio type 3b (HATS 
3,1 kHz improved handsfree) 


5.6 [17] 





N/A 


N/A 


NG1 .SG.23 FP Audio type 1 b (new 
ISDN 3,1 kHz) 


5.6 [17] 


N/A 


G706 


C706 


NG1 .SG.24 PP echo canceller for FP, 
narrowband 


5.6 [17] 


N/A 


G707 


C707 


NG1 .SG.25 PP echo supressor for FP, 
narrowband 


5.6 [17] 


N/A 


G707 


C707 
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Service/DECT Feature mapping 




Status 1 


Service 


lA 


DECT feature/service 


Reference 


PT 


FT 1 


R/B 


P 


NG1 .SC.26 FP Audio type 2 (analog 
PSTN 3,1 kHz) 


5.6 [17] 


N/A 


C706 


C706 


NG1 .SC.27 FP Audio type 3 (VoIP 
3,1 l<Hz) 


5.6 [17] 


N/A 


C706 


C706 


NG1 .SC.32 FP Audio type 6a (internal 
call) 


5.6 [17] 


N/A 


M 


M 


NG1 .SC.33 FP Audio type 6b (internal 
conference) 


5.6 [17] 


N/A 








NG1 .SG.34 Adaptive volume control for 
FP 


5.6 [17] 


N/A 








NG1.2 Narrow band PCIM G.711 
64 l<bit/s voice service 


II 




5.1 [17] 











NG1.P.1 2 level GFSK modulation 


5.5 [17] 


M 


M 


M 


NG1.P.4 Physical Packet P67 


5.5 [17] 


M 


M 


M 


NG1.M.3 lpQ_error_detection symmetric 
I\/1AG service type 


5.4 [17] 


M 


M 


M 


NG1 MA Advanced Connections 


5.4 [17] 


M 


M 


M 


NG1.D.1 DLC Service LU1 TRUP Glass 
0/min delay 


5.3 [17] 


M 


M 


M 


NG1.D.5DLG frame FU1 


5.3 [17] 


M 


M 


M 


NG1.SC.2 

Recommendation ITU-T G.711 [13] 

64 kbit/s PGIVI codec 


5.6 [17] 


M 


M 


M 


NG1.SG.8 Detection of Fax/modem 
tone 


5.6 [17] 











NG1 .SC.9 Codec selection and 
switching 


5.6 [17] 


M 


M 


M 


NG1.SC.10 PP Audio type la (classic 
GAP handset) 


5.6 [17] 


1 


N/A 


N/A 


NG1.SC.11 PP Audio type 1b 
(improved GAP handset) 


5.6 [17] 


1 


N/A 


N/A 


NG1.SC.12 PP Audio type 1c (HATS 
3,1 kHz handset) 


5.6 [17] 


C702 


N/A 


N/A 


NG1.SC.13 PP Audio type Id (HATS 
3,1 kHz improved handset) 


5.6 [17] 


C702 


N/A 


N/A 


NG1 .SCI 7 PP Audio type 3a (HATS 
3,1 kHz handsfree) 


5.6 [17] 





N/A 


N/A 


NG1 .SCI 8 PP Audio type 3b (HATS 
3,1 kHz improved handsfree) 


5.6 [17] 





N/A 


N/A 


NG1 .SC.23 FP Audio type 1 b (new 
ISDN 3,1 kHz) 


5.6 [17] 


N/A 


C706 


C706 


NG1 .SC.24 PP echo canceller for FP, 
narrowband 


5.6 [17] 


N/A 


C707 


C707 


NG1 .SC.25 PP echo supressor for FP, 
narrowband 


5.6 [17] 


N/A 


C707 


C707 


NG1 .SC.26 FP Audio type 2 (analog 
PSTN 3,1 kHz) 


5.6 [17] 


N/A 


C706 


C706 


NG1 .SC.27 FP Audio type 3 (VoIP 
3,1 kHz) 


5.6 [17] 


N/A 


C706 


C706 


NG1 .SC.32 FP Audio type 6a (internal 
call) 


5.6 [17] 


N/A 


M 


M 


NG1 .SC.33 FP Audio type 6b (internal 
conference) 


5.6 [17] 


N/A 








NG1 .SC.34 Adaptive volume control for 
FP 


5.6 [17] 


N/A 
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Service/DECT Feature mapping 




Status 1 


Service 


lA 


DECT feature/service 


Reference 


PT 


FT 1 


R/B 


P 


NG1.2 Narrow band PCIM G.711 
64 l<bit/s voice service 


III 




5.1 [17] 











NG1.P.1 2 level GFSK modulation 


5.5 [17] 


M 


M 


M 


NG1.P.5 Physical Packet P80 


5.5 [17] 


M 


M 


M 


NG1.M.2 lN_normal_delay symmetric 
MAG service type 


5.4 [17] 


M 


M 


M 


NG1 .MA Advanced Connections 


5.4 [17] 


M 


M 


M 


NG1 .D.3 DLG service LU7 64 kbit/s 
protected bearer service 


5.3 [17] 


M 


M 


M 


NG1.D.6DLC frame FU7 


5.3 [17] 


M 


M 


M 


NG1.SC.2 

Recommendation ITU-T G.711 [13] 

64 kbit/s PCIVI codec 


5.6 [17] 


M 


M 


M 


NG1.SC.8 Detection of Fax/modem 
tone 


5.6 [17] 











NG1 .SG.9 Codec selection and 
switching 


5.6 [17] 


M 


M 


M 


NG1.SC.10 PP Audio type la (classic 
GAP handset) 


5.6 [17] 


1 


N/A 


N/A 


NG1.SC.11 PP Audio type lb 
(improved GAP handset) 


5.6 [17] 


1 


N/A 


N/A 


NG1.SC.12PP Audio type 1c (HATS 
3,1 kHz handset) 


5.6 [17] 


C702 


N/A 


N/A 


NG1.SC.13 PP Audio type Id (HATS 
3,1 kHz improved handset) 


5.6 [17] 


C702 


N/A 


N/A 


NG1 .SC.17 PP Audio type 3a (HATS 
3,1 kHz handsfree) 


5.6 [17] 





N/A 


N/A 


NG1 .SCI 8 PP Audio type 3b (HATS 
3,1 kHz improved handsfree) 


5.6 [17] 





N/A 


N/A 


NG1 .SC.23 FP Audio type 1 b (new 
ISDN 3,1 kHz) 


5.6 [17] 


N/A 


C706 


C706 


NG1 .SC.24 PP echo canceller for FP, 
narrowband 


5.6 [17] 


N/A 


C707 


C707 


NG1 .SC.25 PP echo supressor for FP, 
narrowband 


5.6 [17] 


N/A 


C707 


C707 


NG1 .SC.26 FP Audio type 2 (analog 
PSTN 3,1 kHz) 


5.6 [17] 


N/A 


C706 


C706 


NG1 .SC.27 FP Audio type 3 (VoIP 
3,1 kHz) 


5.6 [17] 


N/A 


C706 


C706 


NG1 .SC.32 FP Audio type 6a (internal 
call) 


5.6 [17] 


N/A 


M 


M 


NG1 .SC.33 FP Audio type 6b (internal 
conference) 


5.6 [17] 


N/A 








NG1 .SC.34 Adaptive volume control for 
FP 


5.6 [17] 


N/A 
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Service/DECT Feature mapping 




Status 1 


Service 


lA 


DECT feature/service 


Reference 


PT 


FT 1 


R/B 


P 


NG1 .3 Wideband 7 kHz G.722 
64 l<bit/s voice service 


1 




5.1 [17] 


IVI 


IVI 


M 


NG1.P.1 2 level GFSK modulation 


5.5 [17] 


M 


M 


M 


NG1.P.3 Physical Packet P64 


5.5 [17] 


M 


M 


M 


NG1.M.1 lN_minimum delay symmetric 
MAG service type 


5.4 [17] 


M 


M 


M 


NG1 .MA Advanced Connections 


5.4 [17] 


M 


M 


M 


NG1.D.1 DLG Service LU1 TRUP Class 
0/min delay 


5.3 [17] 


M 


M 


M 


NG1.D.5 DLG frame FU1 


5.3 [17] 


M 


M 


M 


NG1.SC.3 

Recommendation ITU-T G.722 [14] 

64 kbit/s 7 kHz wideband codec 


5.6 [17] 


M 


M 


M 


NG1.SC.7 Packet loss Concealment 

(PLC) for 

Recommendation ITU-T G.722 [14] 


5.6 [17] 











NG1 .SC.9 Codec selection and 
switching 


5.6 [17] 


M 


M 


M 


NG1.SC.14PP Audio type 2a 
(Recommendation ITU-T P.311 [i.6] 
7 kHz handset) 


5.6 [17] 


1 


N/A 


N/A 


NG1 .SCI 5 PP Audio type 2b (HATS 
7 kHz handset) 


5.6 [17] 


C703 


N/A 


N/A 


NG1 .SCI 6 PP Audio type 2c (HATS 
7 kHz improved handset) 


5.6 [17] 


C703 


N/A 


N/A 


NG1 .SCI 9 PP Audio type 4a (HATS 
7 kHz handsfree) 


5.6 [17] 





N/A 


N/A 


NG1 .SC.20 PP Audio type 4b (HATS 
7 kHz improved handsfree) 


5.6 [17] 





N/A 


N/A 


NG1 .SC.28 FP Audio type 4 (ISDN 
wideband) 


5.6 [17] 


N/A 


C708 


C708 


NG1 .SC.29 FP Audio type 5 (VoIP 
wideband) 


5.6 [17] 


N/A 


C708 


C708 


NG1 .SC.30 NG1 .SC.24 PP echo 
canceller for FP, wideband 


5.6 [17] 


N/A 


C709 


C709 


NG1.SC.31 NG1.SC.24PPecho 
supressor for FP, wideband 


5.6 [17] 


N/A 


C709 


C709 


NG1 .SC32 FP Audio type 6a (internal 

call) 


5.6 [17] 


N/A 


M 


M 


NG1 .SC.33 FP Audio type 6b (internal 
conference) 


5.6 [17] 


N/A 








NG1 .SC.34 Adaptive volume control 


5.6 [17] 


N/A 
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Service/DECT Feature mapping 




Status 1 


Service 


lA 


DECT feature/service 


Reference 


PT 


FT 1 


R/B 


P 


NG1 .3 Wideband 7 WHz G.722 
64 l<bit/s voice service 


II 




5.1 [17] 











NG1.P.1 2 level GFSK modulation 


5.5 [17] 


M 


M 


M 


NG1.P.3 Physical Packet P67 


5.5 [17] 


M 


M 


M 


NG1.M.3 lpQ_error_detection symmetric 
IVIAG service type 


5.4 [17] 


M 


M 


M 


NG1 .MA Advanced Connections 


5.4 [17] 


M 


M 


M 


NG1.D.1 DLG Service LU1 TRUP Class 
0/min delay 


5.3 [17] 


M 


M 


M 


NG1.D.5 DLG frame FU1 


5.3 [17] 


M 


M 


M 


NG1.SC.3 

Recommendation ITU-T G.722 [14] 

64 kbit/s 7 kHz wideband codec 


5.6 [17] 


M 


M 


M 


NG1.SC.7 Packet loss Concealment 

(PLC) for 

Recommendation ITU-T G.722 [14] 


5.6 [17] 











NG1 .SC.9 Codec selection and 
switching 


5.6 [17] 


M 


M 


M 


NG1.SC.14PP Audio type 2a 
(Recommendation ITU-T P.311 [1.6] 
7 kHz handset) 


5.6 [17] 


1 


N/A 


N/A 


NG1 .SCI 5 PP Audio type 2b (HATS 
7 kHz handset) 


5.6 [17] 


C703 


N/A 


N/A 


NG1 .SCI 6 PP Audio type 2c (HATS 
7 kHz improved handset) 


5.6 [17] 


C703 


N/A 


N/A 


NG1 .SCI 9 PP Audio type 4a (HATS 
7 kHz handsfree) 


5.6 [17] 





N/A 


N/A 


NG1 .SC.20 PP Audio type 4b (HATS 
7 kHz improved handsfree) 


5.6 [17] 





N/A 


N/A 


NG1 .SC.28 FP Audio type 4 (ISDN 
wideband) 


5.6 [17] 


N/A 


C708 


C708 


NG1 .SC.29 FP Audio type 5 (VoIP 
wideband 


5.6 [17] 


N/A 


C708 


C708 


NG1 .SC.30 NG1 .SC.24 PP echo 
canceller for FP, wideband 


5.6 [17] 


N/A 


C709 


C709 


NG1.SC.31 NG1.SC.24PPecho 
supressor for FP, wideband 


5.6 [17] 


N/A 


C709 


C709 


NG1 .SC32 FP Audio type 6a (internal 

call) 


5.6 [17] 


N/A 


M 


M 


NG1 .SC.33 FP Audio type 6b (internal 
conference) 


5.6 [17] 


N/A 








NG1 .SC.34 Adaptive volume control 


5.6 [17] 


N/A 
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Service/DECT Feature mapping 




Status 1 


Service 


lA 


DECT feature/service 


Reference 


PT 


FT 1 


R/B 


P 


NG1 .4 Wideband 7 WHz G.729.1 
32 l<bit/s voice service 


1 




5.1 [17] 











NG1.P.1 2 level GFSK modulation 


5.5 [17] 


M 


M 


M 


NG1.P.3 Physical Packet P32 


5.5 [17] 


M 


M 


M 


NG1.M.2 lN_normal_delay symmetric 
MAG service type 


5.4 [17] 


M 


M 


M 


NG1 .MA Advanced Connections 


5.4 [17] 


M 


M 


M 


NG1 .D.4 DLG service LU12 (UNF) 
Class 


5.3 [17] 


M 


M 


M 


NG1 .D.7 DLC frame FU12 with 
adaptation for codec G.729.1 


5.3 [17] 


M 


M 


M 


NG1.SC.4 

Recommendation ITU-T G.729.1 [15] 

32 kbit/s 7 kHz wideband codec 


5.6 [17] 


M 


M 


M 


NG1 .SC.9 Codec selection and 
switching 


5.6 [17] 


M 


M 


M 


NG1.SC.14PP Audio type 2a 
(Recommendation ITU-T P.311 [i.6] 
7 kHz handset) 


5.6 [17] 


1 


N/A 


N/A 


NG1 .SCI 5 PP Audio type 2b (HATS 
7 kHz handset) 


5.6 [17] 


C703 


N/A 


N/A 


NG1 .SCI 6 PP Audio type 2c (HATS 
7 kHz improved handset) 


5.6 [17] 


C703 


N/A 


N/A 


NG1 .SCI 9 PP Audio type 4a (HATS 
7 kHz handsfree) 


5.6 [17] 





N/A 


N/A 


NG1 .SC.20 PP Audio type 4b (HATS 
7 kHz improved handsfree) 


5.6 [17] 





N/A 


N/A 


NG1 .SC.28 FP Audio type 4 (ISDN 
wideband) 


5.6 [17] 


N/A 


C708 


C708 


NG1 .SC.29 FP Audio type 5 (VoIP 
wideband 


5.6 [17] 


N/A 


C708 


C708 


NG1 .SC.30 NG1 .SC.24 PP echo 
canceller for FP, wideband 


5.6 [17] 


N/A 


C709 


C709 


NG1.SC.31 NG1.SC.24PPecho 
supressor for FP, wideband 


5.6 [17] 


N/A 


C709 


C709 


NG1 .SC.32 FP Audio type 6a (internal 
call) 


5.6 [17] 


N/A 


M 


M 


NG1 .SC.33 FP Audio type 6b (Internal 
conference) 


5.6 [17] 


N/A 








NG1 .SC.34 Adaptive volume control 


5.6 [17] 


N/A 
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Service/DECT Feature mapping 




Status 1 


Service 


lA 


DECT feature/service 


Reference 


PT 


FT 1 


R/B 


P 


NG1.5 Superwideband 14 l<Hz 
IVIPEG-4 ER AAC-LD 64 l<bit/s 
voice service 


1 




5.1 [17] 











NG1.P.1 2 level GFSK modulation 


5.5 [17] 


M 


M 


M 


NG1.P.3 Physical Packet P64 


5.5 [17] 


M 


M 


M 


NG1.M.2 lN_normal_delay symmetric 
MAG service type 


5.4 [17] 


M 


M 


M 


NG1 .MA Advanced Connections 


5.4 [17] 


M 


M 


M 


NG1 .D.2 DLG Service LU1 Class 


5.4 [17] 


M 


M 


M 


NG1.D.5DLC frame FU1 


5.3 [17] 


M 


M 


M 


NG1 .SC.5 MPEG4 AAC-LD 64 kbit/s 
14 kHz superwideband codec 


5.6 [17] 


M 


M 


M 


NG1 .SC.9 Codec selection and 
switching 


5.6 [17] 


M 


M 


M 


NG1.SC.21 PP Audio type 5a 
(Superwideband 14 KHz handset) 


5.6 [17] 


M 


N/A 


N/A 


NG1.SC.22PP Audio type 5b 
(Superwideband 14 KHz handsfree) 


5.6 [17] 





N/A 


N/A 


NG1 .SC.28 FP Audio type 4 (ISDN 
wideband) 


5.6 [17] 


N/A 


C708 


C708 


NG1 .SC.29 FP Audio type 5 (VoIP 
wideband) 


5.6 [17] 


N/A 


C708 


C708 


NG1 .SC.32 FP Audio type 6a (internal 
call) 


5.6 [17] 


N/A 


M 


M 


NG1 .SC.33 FP Audio type 6b (internal 
conference) 


5.6 [17] 


N/A 








NG1 .SC.34 Adaptive volume control for 
FP 


5.6 [17] 


N/A 








NG1.5 Superwideband 14 I^Hz 
MPEG-4 ER AAC-LD 64 l^bit/s 
voice service 


II 




5.1 [17] 











NG1.P.1 2 level GFSK modulation 


5.5 [17] 


M 


M 


M 


NG1.P.3 Physical Packet P67 


5.5 [17] 


M 


M 


M 


NG1.M.3 lpQ_error_detection symmetric 
IVIAC service type 


5.4 [17] 


M 


M 


M 


NG1 MA Advanced Connections 


5.4 [17] 


M 


M 


M 


NG1 .D.2 DLC service LU1 Class 


5.3 [17] 


M 


M 


M 


NG1.D.5DLC frame FU1 


5.3 [17] 


M 


M 


M 


NG1 .SC.5 MPEG4 AAC-LD 64 kbit/s 
14 kHz superwideband codec 


5.6 [17] 


M 


M 


M 


NG1 .SC.9 Codec selection and 
switching 


5.6 [17] 


M 


M 


M 


NG1.SC.21 PP Audio type 5a 
(Superwideband 14 KHz handset) 


5.6 [17] 


M 


N/A 


N/A 


NG1.SC.22PP Audio type 5b 
(Superwideband 14 KHz handsfree) 


5.6 [17] 





N/A 


N/A 


NG1 .SC.28 FP Audio type 4 (ISDN 
wideband) 


5.6 [17] 


N/A 


C708 


C708 


NG1 .SC.29 FP Audio type 5 (VoIP 
wideband) 


5.6 [17] 


N/A 


C708 


C708 


NG1 .SC.32 FP Audio type 6a (internal 
call) 


5.6 [17] 


N/A 


M 


M 


NG1 .SC.33 FP Audio type 6b (internal 
conference) 


5.6 [17] 


N/A 








NG1 .SC.34 Adaptive volume control for 
FP 


5.6 [17] 


N/A 
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Service/DECT Feature mapping 




Status 1 


Service 


lA 


DECT feature/service 


Reference 


PT 


FT 1 


R/B 


P 


NG1.6 Wideband 11 l<Hz IVIPEG-4 
ER AAC-LD 32 l<bit/s voice 
service 


1 




5.1 [17] 











NG1.P.1 2 level GFSK modulation 


5.5 [17] 


M 


M 


M 


NG1.P.3 Physical Packet P32 


5.5 [17] 


M 


M 


M 


NG1.M.2 lN_normal_delay symmetric 
MAO service type 


5.4 [17] 


M 


M 


M 


NG1 .MA Advanced Oonnections 


5.4 [17] 


M 


M 


M 


NG1 .D.2 DLO service LU1 Glass 


5.4 [17] 


M 


M 


M 


NG1.D.5DLG frame FU1 


5.3 [17] 


M 


M 


M 


NG1 .SG.6 MPEG4 AAO-LD 32 kbit/s 
1 1 kHz wideband codec 


5.6 [17] 


M 


M 


M 


NG1 .S0.9 Oodec selection and 
switching 


5.6 [17] 


M 


M 


M 


NG1.SG.14PP Audio type 2a 
(Recommendation ITU-T P.311 [1.6] 
7 kHz handset) 


5.6 [17] 


1 


N/A 


N/A 


NG1 .SG.1 5 PP Audio type 2b (HATS 
7 kHz handset) 


5.6 [17] 


G703 


N/A 


N/A 


NG1 .SG.1 6 PP Audio type 2c (HATS 
7 kHz improved handset) 


5.6 [17] 


G703 


N/A 


N/A 


NG1 .SG.1 9 PP Audio type 4a (HATS 
7 kHz handsfree) 


5.6 [17] 





N/A 


N/A 


NG1 .SG.20 PP Audio type 4b (HATS 
7 kHz improved handsfree) 


5.6 [17] 





N/A 


N/A 


NG1 .SG.28 FP Audio type 4 (ISDN 
wideband) 


5.6 [17] 


N/A 


G708 


0708 


NG1 .SG.29 FP Audio type 5 (VoIP 
wideband) 


5.6 [17] 


N/A 


G708 


0708 


NG1 .SG.30 NG1 .S0.24 PP echo 
canceller for FP, wideband 


5.6 [17] 


N/A 


G709 


0709 


NG1.SG.31 NG1.S0.24PPecho 
supressor for FP, wideband 


5.6 [17] 


N/A 


G709 


0709 


NG1 .SG.32 FP Audio type 6a (internal 

call) 


5.6 [17] 


N/A 


M 


M 


NG1 .SG.33 FP Audio type 6b (internal 
conference) 


5.6 [17] 


N/A 








NG1 .SG.34 Adaptive volume control 


5.6 [17] 


N/A 








lA = Implementation Alternative: 

C201 : Advanced connections for Service NG1 .1 shall only be used in the case of multiple connections 

between the same PT-FT pair. The support of this case is optional. 
C702: At least one should be provided. 
C703: At least one should be provided. 
C706: At least one should be provided. 
C707: IF feature NG1 .SC.23 (FP type 1 b) OR NG1 .SG.27 (FP type 3) THEN ELSE 1. Either NG1 .SC.24 or 

NG1 .SC.25 may be provided, but not both at the same time. 
0708: At least one should be provided. 
0709: IF feature NG1 .S0.28 (FP type 4) OR NG1 .S0.29 (FP type 5) THEN ELSE 1. Either NG1 .SO.30 or 

NG1 .SO. 31 may be provided, but not both at the same time. 
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6.4 



NWK features 



"New Generation DECT; Part 5: Additional feature set nr. 1 for extended wideband speech services" devices shall 
support the following Network layer features. 

Table 3: NWK features status 



Feature supported 




Status 1 


Item no. 


Name of feature 


Reference 


PT 


FT 1 


R/B 


P 


NG1.N.1 


Codec Negotiation 


5.2 [17] 


M 


M 


M 


NG1.N.2 


Codec Switching 


5.2 [171 


M 


M 


M 


NG1.N.3 


IVIissed call notification 


5.2 [18] 


M 


M 


M 


NG1.N.4 


Voice message waiting notification 


5.2(18] 


M 


M 


M 


NG1.N.5 


Date and Time synchronization 


5.2 [18] 


M 


M 


M 


NG1.N.6 


Parallel calls 


5.2 [18] 


M 


M, 
note 7 





NG1.N.7 


Common parallel call procedures (external or internal) 


5.2 [18] 


M 


M, 
note 7 





NG1.N.8 


Call transfer (external or internal) 


5.2 [18] 


M 


M 





NG1.N.9 


3-party conference with established external and/or internal 
calls 


5.2 [18] 


M 


M 


0, 
note 6 


NG1.N.10 


Intrusion call 


5.2 [18] 


M 


M 


0, 
note 6 


NG1.N.11 


Call deflection (external or internal) 


5.2 [18] 





0, 
note 6 


0, 
note 6 


NG1.N.12 


Line identification 


5.2 [18] 


M 


M 


M 


NG1.N.13 


Call identification 


5.2 [18] 


M 


M 


M 


NG1.N.14 


Multiple Lines 


5.2 [18] 


M 








NG1.N.15 


IVlultiple calls 


5.2 [18] 


M 


M 





NG1.N.16 


List access service 


5.2 [18] 


M 


M 





NG1.N.17 


Calling line identity restriction 


5.2 [18] 


M 


M 





NG1.N.18 


Call forwarding (external calls) 


5.2 [18] 


M 


M 


1 


NG1.N.19 


DTMF handling 


5.2 [18] 


M 


M 





NG1.N.20 


Tones provision 


5.2 [18] 


M 


M 





NG1.N.21 


Headset management 


5.2 [18] 


C301 


M 





NG1.N.22 


Handling of lines where second calls are signalled in-band 


5.2 [18] 


M 


0, 
note 7 





NG1.N.23 


Line and diagnostic information 


5.2 


M 


M 





NG1.N.24 


Short Message Service 


5.2 











NG1.N.25 


DTAM support 


5.2 











NG1.N.26 


Screening support 


5.2 











GAP. N.I 


Outgoing call 


4.1 [11] 


M 


M 


M 


GAP.N.2 


Off hook 


4.1 [11] 


M 


M 


M 


GAP.N.3 


On hook (full release) 


4.1 [11] 


M 


M 


M 


GAP.N.4 


Dialled digits (basic) 


4.1 [11] 


M 


M 


M 


GAP.N.5 


Register recall (see notes 4 and 5) 


4.1 [11] 


M 








GAP.N.6 


Go to DTMF signalling (defined tone length) (see note 1) 


4.1 [11] 


M 





M 


GAP.N.7 


Pause (dialling pause) (see note 3) 


4.1 [11] 


M 








GAP.N.8 


Incoming call 


4.1 [11] 


M 


M 


M 


GAP.N.9 


Authentication of PP 


4.1 [11] 


M 


M 


M 


GAP.N10 


Authentication of user (see note 2) 


4.1 [11] 


M 








GAP.N.11 


Location registration 


4.1 [11] 


M 





M 


GAP.N.12 


On air key allocation (see note 2) 


4.1 [11] 


M 


M 





GAP.N.13 


Identification of PP 


4.1 [11] 


M 








GAP.N.14 


Service class indication/assignment 


4.1 [11] 


M 





M 


GAP.N.15 


Alerting 


4.1 [11] 


M 


M 


M 


GAP.N.16 


ZAP (see note 2) 


4.1 [11] 


M 








GAP.N.17 


Encryption activation FT initiated 


4.1 [11] 


M 


M 


M 


GAP.N.18 


Subscription registration procedure on-air 


4.1 [11] 


M 


M 


M 


GAP.N.19 


Link control 


4.1 [11] 


M 


M 


M 


GAP.N.20 


Terminate access rights FT initiated (see note 2) 


4.1 [11] 


M 


M 





GAP.N.21 


Partial release 


4.1 [11] 
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Feature supported 




Status 1 


Item no. 


Name of feature 


Reference 


PT 


FT 1 


R/B 


P 


GAP.N.22 


Go to DTIVIF (infinite tone length) 


4.1 [11] 











GAP.N.23 


Go to Pulse 


4.1 [11] 











GAP.N.24 


Signalling of display characters 


4.1 [11] 











GAP.N.25 


Display control characters 


4.1 [11] 











GAP.N.26 


Authentication of FT 


4.1 [11] 











GAP.N.27 


Encryption activation PT initiated 


4.1 [11] 











GAP.N.28 


Encryption deactivation FT initiated 


4.1 [11] 











GAP.N.29 


Encryption deactivation PT initiated 


4.1 [11] 











GAP.N.30 


Galling Line Identification Presentation (CLIP) 


4.1 [11] 


M 


M 


M 


GAP.N.31 


Internal call 


4.1 [11] 


M 


M 


M 


GAP.N.32 


Service call 


4.1 [11] 











GAP.N.33 


Enhanced U- plane connection 


4.1 [11] 











GAP.N.34 


Calling Name Identification Presentation (CNIP) 


4.1 [11] 


M 


M 


M 


GAP.N.35 


Enhanced security 


4.1 [11] 


M 


M 


M 


GAP.N.36 


AES/DSAA2 authentication 


4.1 [11] 











C301 : IF the PT is a headset PP THEN "M" ELSE "1". 


NOTE 1 : The PT is only required to be able to send the «I\/IULTI-KEYPAD» information element containing the 

DECT standard 8-bit character (EN 300 175-5 [5], annex D) codings "Go to DTMF", defined tone length 

and the FT is required to be able to understand it in the public environment. 
NOTE 2: This feature is required to be supported in the PT to guarantee the same level of security among all the 

handsets that operates in a system. The invocation of the feature is however optional to the operator. 
NOTE 3: The PT is required to be able to send the «MULTI-KEYPAD» information element containing the DECT 

standard 8-bit character (EN 300 175-5 [5], annex D) codings "Dialling Pause". This guarantees 

automatic access to secondary or alternative networks. 
NOTE 4: This feature uses keypad code 15 hex. 
NOTE 5: The FT is not mandated to receive and understand the register recall DECT character. However, if a FT 

supports it there may be no corresponding action that the FT can take with the local network as a result of 

this function. 
NOTE 6: If the feature is not supported on FT side, the FT shall however implement the "sending negative 

acknowledgement" procedure (see clause 7.4.3.4 of TS 102 527-3 [18]). 
NOTE 7: All procedures of NG1 .N.6 and NG1 .N.7 shall apply to all FTs and for all line types (full parallel call 

compliant lines and DGIBS lines). For DGIBS lines, the FT shall implement in addition NG1 .N.22 feature, 

which describes some amendments to NG1 .N.6 and NG1 .N.7 for such lines. A given FT shall be 

designed to handle both line types, or only one of them. 



6.5 Data Link Control (DLC) services 

"New Generation DECT; Part 5: Additional feature set nr. 1 for extended wideband speech services" devices shall 
support the following DLC services. 
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Table 4: DLC services status 



Service supported 




Status 1 


Item no. 


Name of service 


Reference 


PT 


FT 1 


R/B 


P 


NG1.D.1 


LU1 Transparent Unprotected service (TRUP) Class 
/minimum delay 


5.S[17] 


M 


M 


M 


NG1.D.2 


LU1 Transparent Unprotected service (TRUP) Class 


5.3 [17] 


C001 


C001 


C001 


NG1.D.3 


LU7 64 kbit/s protected bearer service 


5.S[17] 


C001 


C001 


C001 


NG1.D.4 


LU 12 Unprotected Framed service (UNF) Class 


5.S[17] 


C001 


C001 


C001 


NG1.D.5 


FU1 DLC frame 


5.S[171 


M 


M 


M 


NG1.D.6 


FU7 DLC frame 


5.Sf171 


C001 


C001 


C001 


NG1.D.7 


FU12 DLC frame with adaptation for codec G.729.1 


5.S[17] 


C401 


C401 


C401 


GAP.D.1 


LAPC class A service and Lc 


5.1 [11] 


M 


M 


M 


GAP.D.2 


Cs channel fragmentation and recombination 


5.1 [111 


M 


M 


M 


GAP.D.3 


Broadcast Lb service 


5.1 [111 


M 


M 


M 


GAP.D.4 


Intra-cell voluntary connection handover 


5.1 [111 


M 


C002 


C002 


GAP.D.5 


Intercell voluntary connection handover (see note) 


5.1 [11] 


M 








GAP.D.6 


Encryption activation 


5.1 [111 


M 


C004 


M 


GAP.D.9 


Encryption deactivation 


5.1 [111 


COOS 


COOS 


COOS 


C001 
C002 
COOS 
C004 


Status defined by clause 6.3, table 2. 

IF service GAP.M.9 THEN ELSE M. 

IF feature GAP.N.29 OR GAP.N.28 THEN M ELSE 1. 

IF feature GAP.N.17 OR GAP.N.27 THEN M ELSE 1. 


NOTE: The PT is required to be able to support liandover between RFPs. The invocation of the feature is 
however optional to the operator. 
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6.6 Medium Access Control (MAC) services 

"New Generation DECT; Part 5: Additional feature set nr. 1 for extended wideband speech services" devices shall 
support the following MAC layer services. 

Table 5: MAC services status 



Service supported 




Status 1 


Item no. 


Name of service 


Reference 


PT 


FT 1 


R/B 


P 


NG1.M.1 


In minimum delay symmetric MAO service type 


5.4 [17] 


M 


M 


M 


NG1.M.2 


In normal delay symmetric MAO service type 


5.4 [171 


C001 


C001 


0001 


NG1.M.3 


IpQ error detection symmetric MAO service type 


5.4 [17] 


C001 


C001 


0001 


NG1.M.4 


Advanced connections 


5.4 [17] 


M 


M 


M 


NG1.M.5 


"no emission" mode 


5.4 [18] 











NG1.M.6 


"low duty cycle Idle Locked" mode 


5.4 











GAP.M.1 


General 


5.2 [11] 


M 


M 


M 


GAP.M.2 


Oontinuous broadcast 


5.2[11] 


M 


M 


M 


GAP.M.3 


Paging broadcast 


5.2 [11] 


M 


M 


M 


GAP.M.4 


Basic connections 


5.2 [11] 


M 


M 


M 


GAP.M.5 


Cs higher layer signalling 


5.2 [11] 


M 


M 


M 


GAP.M.6 


Quality control 


5.2[11] 


M 


M 


M 


GAP.M.7 


Encryption activation 


5.2 [11] 


M 


M 


M 


GAP.M.8 


Extended frequency allocation (see note 1 ) 


5.2 [11] 


M 








GAP.M.9 


Bearer Handover, intra-cell 


5.2 [11] 


M 


C002 


0002 


GAP.M.10 


Bearer Handover, inter-cell 


5.2 [11] 


M 








GAP.M.11 


Connection Handover, intra-cell 


5.2 [11] 


M 


C003 


0003 


GAP.M.12 


Connection Handover, inter-cell 


5.2 [11] 


M 








GAP.M.13 


SARI support 


5.2 [11] 


M 








GAP.M.14 


Encryption deactivation 


5.2 [11] 


C004 


C004 


0004 


GAP.M.15 


Re-keying 


5.2 [11] 


M 


M 


M 


GAP.M.16 


Early encryption 


5.2 [11] 


M 


M 


M 


GAP.M.17 


AES/DS02 encryption (see note 2) 


5.2 [11] 











C001 : Status defined by clause 6.3, table 2. 
C002: IF service GAP.M.1 1 THEN ELSE M. 
0003: IF service GAP.M.9 THEN ELSE M. 
0004: IF feature GAP.N.29 OR N.28 THEN M ELSE \. 


NOTE 1 : Handsets not supporting these extra frequencies need only adapt scanning to allow continued use of the 

standard DECT frequencies. 
NOTE 2: IF implemented THEN NWK feature GAP.N.36 shall be implemented. 



6.7 Physical layer (PHL) services 



"New Generation DECT; Part 5: Additional feature set nr. 1 for extended wideband speech services" devices shall 
support the following Physical layer (PHL) services. 

Table 6: PHL services status 



Service supported 




Status 


Item no. 


Name of service 


Reference 


PT 


FT 1 


R/B 


P 


NG1.P.1 


2 level GFSK modulation 


5.5 [17] 


M 


M 


M 


NG1.P.2 


Physical Packet P32 


5.5 [17] 


M 


M 


M 


NG1.P.3 


Physical Packet P64 


5.5 [17] 


M 


M 


M 


NG1.P.4 


Physical Packet P67 


5.5 [17] 











NG1.P.5 


Physical Packet P80 


5.5 [17] 












The requirements of EN 300 444 [11], clause 11 also apply. 



£75/ 



33 



ETSI TS 102 527-5 V1.1.1 (2013-04) 



6.8 Speech coding and audio features 

"New Generation DECT; Part 5: Additional feature set nr. 1 for extended wideband speech services" devices shall 
support the following Speech coding and audio related features. 



Table 7: Speech Coding and audio features 



Service supported 




Status 1 


Item no. 


Name of service 


Reference 


PT 


FT 1 


R/B 


p 


NG1.SC.1 


G.726 32 kbit/s ADPCM codec 


5.6 [17] 


M 


M 


M 


NG1.SC.2 


G.71 1 64 kbit/s PCM codec 


5.6 [17] 


C701 


C701 


C701 


NG1.SC.3 


G.722 64 kbit/s 7 kHz wideband codec 


5.6 [17] 


M 


M 


M 


NG1.SC.4 


G. 729.1 32 kbit/s 7 kHz wideband codec 


5.6 [17] 


C701 


C701 


C701 


NG1.SC.5 


IVIPEG4 AAC-LD 64 kbit/s 14 kHz superwideband codec 


5.6 [17] 


C701 


C701 


C701 


NG1.SC.6 


MPEG4 AAC-LD 32 kbit/s 1 1 kHz wideband codec 


5.6 [17] 


C701 


C701 


C701 


NG1.SC.7 


Packet Loss Concealment (PLC) for G.722] 


5.6 [17] 


C701 


C701 


C701 


NG1.SC.8 


Detection of Fax/modem tone 


5.6 [17] 


C701 


C701 


C701 


NG1.SC.9 


Codec selection and switching 


5.6 [17] 


M 


M 


M 


NG1.SC.10 


PP Audio profile type la (classic GAP handset) 


5.6 [171 


1 


N/A 


N/A 


NG1.SC.11 


PP Audio profile type lb (improved GAP handset) 


5.6 [17] 


1 


N/A 


N/A 


NG1.SC.12 


PP Audio profile type 1c (HATS 3,1 kHz handset) 


5.6 [17] 


C702 


N/A 


N/A 


NG1.SC.13 


PP Audio profile type Id (HATS 3,1 kHz improved handset) 


5.6 [17] 


C702 


N/A 


N/A 


NG1.SC.14 


PP Audio profile type 2a (Recommendation ITU-T P.31 1 [i.6] 
7 kHz handset) 


5.6 [17] 


1 


N/A 


N/A 


NG1.SC.15 


PP Audio profile type 2b (HATS 7 kHz handset) 


5.6 [17] 


C703 


N/A 


N/A 


NG1.SC.16 


PP Audio profile type 2c (HATS 7 kHz improved handset) 


5.6 [17] 


C703 


N/A 


N/A 


NG1.SC.17 


PP Audio profile type 3a (HATS 3,1 kHz handsfree) 


5.6 [17] 





N/A 


N/A 


NG1.SC.18 


PP Audio profile type 3b (HATS 3,1 kHz improved handsfree) 


5.6 [17] 





N/A 


N/A 


NG1.SC.19 


PP Audio profile type 4a (HATS 7 kHz handsfree) 


5.6 [17] 





N/A 


N/A 


NG1.SC.20 


PP Audio profile type 4b (HATS 7 kHz improved handsfree) 


5.6 [17] 





N/A 


N/A 


NG1.SC.21 


PP Audio profile type 5a superwideband (14 kHz) handset 


5.6 [17] 


C704 


N/A 


N/A 


NG1.SC.22 


PP Audio profile type 5b superwideband (14 kHz) handsfree 


5.6 [17] 


C705 


N/A 


N/A 


NG1.SC.23 


FP Audio type 1 b (new ISDN 3,1 kHz) 


5.6 [17] 


N/A 


C706 


C706 


NG1.SC.24 


PP echo canceller for FP, narrowband 


5.6 [17] 


N/A 


C707 


C707 


NG1.SC.25 


PP echo supressor for FP, narrowband 


5.6 [17] 


N/A 


C707 


C707 


NG1.SC.26 


FP Audio type 2 (analog PSTN 3,1 kHz) 


5.6 [17] 


N/A 


C706 


C706 


NG1.SC.27 


FP Audio type 3 (VoIP 3,1 kHz) 


5.6 [17] 


N/A 


C706 


C706 


NG1.SC.28 


FP Audio type 4 (ISDN wideband) 


5.6 [17] 


N/A 


C708 


C708 


NG1.SC.29 


FP Audio type 5 (VoIP wideband) 


5.6 [17] 


N/A 


C708 


C708 


NG1.SC.30 


PP echo canceller for FP, wideband 


5.6 [17] 


N/A 


C709 


C709 


NG1.SC.31 


PP echo supressor for FP, wideband 


5.6 [17] 


N/A 


C709 


C709 


NG1.SC.32 


FP Audio type 6a (internal call) 


5.6 [17] 


N/A 


M 


M 


NG1.SC.33 


FP Audio type 6b (internal conference) 


5.6 [17] 


N/A 








NG1.SC.34 


Adaptive volume control for FP 


5.6 [17] 


N/A 








C701 
C702 
G703 
G704 
C705 
C706 
C707 

C708 
C709 


Status defined by clause 6.3, table 2. 

At least one should be provided. 

At least one should be provided. 

IF Service NG1.5 (Superwideband) THEN M ELSE 1. 

IF Service NG1 .5 (Superwideband) THEN ELSE 1. 

At least one should be provided. 

IF feature NG1 .SC.23 (FP type 1 b) OR NG1 .SC.27 (FP type 3) THEN ELSE 1. Either NG1 .SC.24 or 

NG1 .SC.25 may be provided, but not both at the same time. 

At least one should be provided. 

IF feature NG1 .SC.28 (FP type 4) OR NG1 .SC.29 (FP type 5) THEN ELSE 1. Either NG1 .SC.30 or 

NG1 .SC.31 may be provided, but not both at the same time. 



NOTE 1: Testing specification for audio features, including handsfree, is provided in EN 300 176-2 [9]. 

NOTE 2: PP types Ic, Id, 2b and 2c are based on HATS methodology. This methodology provides objective test 
results more consistent with subjective tests compared to artificial ear methodology. 
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NOTE 3: All audio types used in the present document are compatible with VoIP or long delay networks. 



6.9 Application features 



"New Generation DECT; Part 5: Additional feature set nr. 1 for extended wideband speech services" devices shall 
support the following Application features. 

Table 8: Application features status 



Feature supported 




Status 1 


Item no. 


Name of feature 


Reference 


PT 


FT 1 


R/B 


P 


NG1.A.1 


Easy PIN code registration 


5.7 [18] 


M 





N/A 


NG1.A.2 


Easy pairing registration 


5.7 [18] 


M 


M 


N/A 


NG1.A.3 


Handset locator 


5.7 [18] 


M 








NG1.A.4 


Base manual transmit power control 


5.7 


N/A 


M 





NG1.A.5 


Handset adaptive transmit power control 


5.7 


M 


N/A 


N/A 


GAP.A.1 


AC bitstring mapping 


4.2 [11] 


M 


M 


M 


GAP.A.2 


IVIultiple subscription registration 


4.2 [11] 


M 


N/A 


N/A 


GAP.A.3 


IVIanual entry of the PARK 


4.2 [11] 





N/A 


N/A 


GAP.A.4 


Terminal identity number assignment in mono cell system 


4.2 [11] 


M 


M 


N/A 



6.1 Network (NWK) feature to procedure mapping 

The NWK features to procedure mapping of EN 300 444 [11] (GAP), clause 6.7 with the following changes and 
additional features shall apply. 

Table 9: NWK feature to procedure mapping 



Feature/Procedure mapping 




Status 1 


Feature 


Procedure 


Reference 


PT 


FT 1 


R/B 


P 


NG1.N.1 Codec Negotiation 




5.2 [17] 


M 


M 


M 


Exchange of codec list during 
registration and location 
registration 


7.3.1 [17] 


M 


M 


M 


Basic service wideband speech 
and default attributes 


7.3.2 [17] 


M 


M 


M 


Codec Negotiation during call 
establishment 


7.3.3 [17] 


M 


M 


M 


NG1 .N.2 Codec Switching 




5.2 [17] 


M 


M 


M 


Codec Change 


7.3.4 [17] 


M 


M 


M 


Slot type modification 


7.3.5 [17] 


M 


M 


M 


MAC layer advanced connection 
slot type modification 


7.6.7 [17] 








MAC layer connection type 
modification: basic to/from 
advanced 


7.6.6 [17] 


M 


M 


M 


NG1.N.3 Missed call notification 




5.2(18] 


M 


M 


M 


Generic events notification, general 


7.4.1.1 [18] 


M 


M 


M 


Missed call notification 


7.4.1.3 


M 


M 


M 


NG1 .N.4 Voice message waiting 
notification 




5.2 [18] 


M 


M 


M 


Generic events notification, general 


7.4.1.1 [18] 


M 


M 


M 


Voice message waiting notification 


7.4.1.2 [18] 


M 


M 


M 


NG1.N.5 Date and Time 
synchronization 




5.2 [18] 


M 


M 


M 


Date and Time synchronization 


7.4.2 [18] 


M 


M 


M 


Date and Time recovery 


7.4.20(18] 


M 


M 


M 



£75/ 



35 



ETSI TS 102 527-5 V1.1.1 (2013-04) 



Feature/Procedure mapping 




Status 1 


Feature 


Procedure 


Reference 


PT 


FT 1 


R/B 


P 


NG1.N.6 Parallel Calls 




5.2 [18] 


M 


M, 
note 2 





Parallel call common requirements 


7.4.3.1 [18] 


M 


M 


M 


Control messages 


7.4.3.2 


M 


M 


M 


Sending Keypad information 


8.10[11] 


M 


M 


M 


Codec change for parallel calls 


7.4.3.3 [18] 


M 


M 


M 


Sending negative 
acknowledgement 


7.4.3.4 [18] 


M 


M 


M 


Busy system or line notification 


7.4.8.3 [18] 


M 


M 


M 


NG1 .N.7 Common parallel call 
procedures (external or internal) 




5.2 [18] 


M 


M, 
note 2 





Outgoing parallel call initiation 
(external or internal) 


7.4.3.5.1 [18] 


M 


M 


M 


Call waiting indication (external or 
internal) 


7.4.3.5.2 [18] 


M 


M 


M 


Call toggle (external or internal) 


7.4.3.5.3 [18] 


M 


M 


M 


Call release and call release 
rejection 


7.4.3.5.4 [18] 


M 


M 


M 












Call waiting acceptance (from PP 
toFP) 


7.4.3.5.6 [18] 


M 


M 


M 


Call waiting rejection (from PP to 
FP) 


7.4.3.5.7 [18] 


M 


M 


M 


Active call release with 
replacement (from PP to FP) 


7.4.3.5.12 [18] 





M 


M 


Putting a call on-hold 


7.4.3.5.8 [18] 





M 


M 


Resuming a call put on-hold 


7.4.3.5.9 [18] 


0, 
note 6 


M 


M 


CLIP on call waiting indication 


7.4.3.5.10 [18] 


M 


M 


M 


CNIP on call waiting indication 


7.4.3.5.11 [18] 


M 


M 


M 




Call remote status notification 


7.4.3.5.13(18] 


M 


M 


M 


NG1 .N.8 Call transfer (external or 
internal) 




5.2 [18] 


M 


M 





Announced call transfer 


7.4.3.6.1 [18] 


M 


M 


M 


Unannounced call transfer 


7.4.3.6.2 [18] 


M 


M 


M 


Call re-injection to the system 
(external or internal) 


7.4.3.6.3 [18] 


M 


M 


M 


Remote party CLIP on call transfer 


7.4.3.6.4 [18] 


M 


M 


M 


Remote party CNIP on call transfer 


7.4.3.6.5 [18] 


M 


M 


M 


NG1 .N.9 3-party conference call 
(external or internal) 




5.2 [18] 


M 


M 




(notel) 


3-party Conference with 
established internal and external 
calls 


7.4.3.7 [18] 


M 


M 


M 


NG1.N.10 Intrusion call 




5.2(18] 


M 


M 




(notel) 


Implicit intrusion call into a line in 
"single call" mode 


7.4.3.8.1 [18] 


C901 


M 


M 


Explicit intrusion call (from PP to 
FP) 


7.4.3.8.2(18] 


C901 


M 


M 


NG1 .N.1 1 Call deflection (internal 
or external) 




5.2(18] 







(notel) 




(notel) 


Call deflection (internal) 


7.4.4.2(18] 


M 


M 


M 


Call deflection (external) 


7.4.4.2(18] 


M 


M 


M 


Call deflection control messages 


7.4.4.1.1 [18] 


M 


M 


M 


NG1.N.12 Line identification 




5.2(18] 


M 


M 


M 


Line identification general 
requirements 


7.4.5.1 [18] 


M 


M 


M 


General line identification 
requirements for external outgoing 
calls 


7.4.5.2.1 [18] 


M 


M 


M 
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Reference 
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R/B 
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Line identification for a first external 
outgoing call using «CALL- 
INFO» IE 


7.4.5.2.2 [18] 


M 


M 


M 


Line identification for a first external 
outgoing call using «MULTI- 
KEYPAD» IE 


7.4.5.2.3 [18] 


1 
(note 5) 


M 


M 


FP managed line selection for a 
first external outgoing call 


7.4.5.2.4 [18] 


M 


M 


M 


General line identification 
requirements for external incoming 
calls 


7.4.5.3.1 [18] 


M 


M 


M 


Line identification for a first external 
incoming call 


7.4.5.3.2 [18] 


M 


M 


M 


NG1.N.13 Call identification 




5.2 [18] 


M 


M 


M 


Call identifier general requirements 


7.4.6.1 [18] 


M 


M 


M 


Call identifier assignment on 
outgoing call (FP to PP) 


7.4.6.2 [18] 


M 


M 


M 


Call identifier assignment on 
incoming call (FP to PP) 


7.4.6.3 [18] 


M 


M 


M 


Call status indication to the 
handset 


7.4.6.4 [18] 


M 


M 


M 


NG1.N.14 Multiple lines 




5.2 [18] 


M 








Multiple lines common 
requirements 


7.4.7.1 [18] 


M 


M 


M 


Terminal attachment and line 
settings 


7.4.7.2 [18] 


M 


M 


M 


Incoming and outgoing external 
calls on a multiple line system 


7.4.7.3 [18] 


M 


M 


M 


Internal calls in multiple line context 


7.4.7.4 [18] 


M 


M 


M 


Compatibility with non multiple line 
PPorFP 


7.4.7.5 [18] 


M 


M 


M 


NG1.N.15 Multiple calls 




5.2 [18] 


M 


M 





Multiple calls general requirements 


7.4.8.1 [18] 


M 


M 


M 


Incoming and outgoing external 
calls on a multiple call line 


7.4.8.2 [18] 


M 


M 


M 


Busy system or line notification 


7.4.8.3 [18] 


M 


M 


M 


NG1 .N.1 6 List access service 




5.2(18] 


M 


M 





General considerations 


7.4.10.1 


M 


M 


M 


List change notification 


7.4.10.2 





M 


M 


Extended list change notification 


7.4.10.7 





M 


M 


Start / end session (note 4) 


7.4.10.4.1 


M 


M 


M 


Query supported entry fields 
(note 4) 


7.4.10.4.2 





M 


M 


Read entries (note 4) 


7.4.10.4.3 


M 


M 


M 


Edit entry (note 4) 


7.4.10.4.4 


M 


M 


M 


Save entry (note 4) 


7.4.10.4.5 


M 


M 


M 


Delete entry (note 4) 


7.4.10.4.6 


M 


M 





Delete list (note 4) 


7.4.10.4.7 


M 


M 


M 


Search entries (note 4) 


7.4.10.4.8 


M 


M 


M 


Negative acknowledgement 


7.4.10.4.9 


M 


M 


M 


Data packet / Data packet last 


7.4.10.4.10 


M 


M 


M 


DECT system and line settings 
considerations 


7.4.11.1 [18] 


M 


M 





Interactions between registration, 
attachment of handsets and lists 


7.4.1 1.2 [18] 


M 


M 





Fields description 


7.4.10.5.1 [18] 


M 


M 


M 


Abnormal release in case of call 
setup collisions 


9.5.2.3 [5] 


M 


M 


M 


[Supported lists] 










List of Supported Lists 


7.4.10.5.2(18] 





M 


M 


Missed Calls List 


7.4.10.5.3(18] 


M 


M 


M 



£75/ 



37 



ETSI TS 102 527-5 V1.1.1 (2013-04) 



Feature/Procedure mapping 




Status 1 


Feature 


Procedure 
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Outgoing Calls List 


7.4.10.5.4 [18] 











Incoming Accepted Calls List 


7.4.10.5.5 [18] 


M 


M 


M 


All Calls List 


7.4.10.5.6 [18] 





M 


M 


Contact List 


7.4.10.5.7 [18] 


M 


M 


M 


Internal Names List 


7.4.10.5.8 [18] 


M 


M 


M 


All Incoming Calls List 


7.4.10.5.11 [18] 











DECT System Settings List 


7.4.1 1.3 [181 


M 


M 





Line Settings List 


7.4.1 1.4 [18] 


M 


M 





Virtual Contact List and call list 
per line 


7.4.1 1.5 [18] 





C902 





Line and Diagnostic Statuses List 


7.4.34.3 


M 


M 





SIVIS Settings List 


7.4.35.4.1 


C912 


C912 


C913 


Incoming SIVIS List 


7.4.35.5.2 


C912 


C912 


C913 


Sent SMS List 


7.4.35.5.3 


C912 


C912 


C913 


Outgoing SMS List 


7.4.35.5.4 


C912 


C912 


C913 


Draft SMS List 


7.4.35.5.5 


C912 


C912 


C913 


DTAM Settings List 


7.4.36.5.2 


C914 


C914 


C914 


DTAM Incoming Calls List 


7.4.36.5.3 


C915 
(note 7) 


C915 
(note 7) 


C915 
(note 7) 


DTAM Welcome Message List 


7.4.36.5.4 


C914 


C914 


C914 


[Supported DECT system 
settings] 










Current PIN code 


7.4.11.3.1 [18] 


M 


M 





Clock master 


7.4.11.3.2 [18] 


M 


M 





Base reset 


7.4.11.3.3 [18] 


M 


M 





FP IP address /type 


7.4.11.3.4 [18] 











FP IP address / value 


7.4.11.3.5 [18] 











FP IP address / subnet mask 


7.4.11.3.6 [18] 











FP IP address / gateway 


7.4.11.3.7 [18] 











FP IP address / DNS server 


7.4.11.3.8 [18] 











FP version / Firmware version 


7.4.11.3.9 [18] 


M 


M 





FP version / EEprom version 


7.4.11.3.10 [18] 


M 


M 





FP version / Hardware version 


7.4.11.3.11 [18] 











Emission mode 


7.4.11.3.12 [18] 


C903 


C903 





New PIN code 


7.4.11.3.13 [18] 


M 


M 





Transmit power mode 


7.4.11.3.14 


M 


M 





[Supported line settings] 










Line name 


7.4.11.4.1 [18] 


M 


M 





Line id 


7.4.11.4.2 [18] 


M 


M 





Attached handsets 


7.4.11.4.3 [18] 


M 


M 





Dialling prefix 


7.4.11.4.4 [18] 











FP melody 


7.4.11.4.5 [18] 











FP volume 


7.4.11.4.6 [18] 











Blocked number 


7.4.11.4.7(18] 











Multiple calls mode 
(single/multiple) 


7.4.11.4.8 [18] 


M 


M 


M 


Intrusion call 


7.4.11.4.9 [18] 


M 


M 


C904 


Permanent CLIR 


7.4.11.4.10 [18] 


M 


M 


C905 


Call forwarding Unconditional 


7.4.11.4.11 [18] 


M 


M 


1 


Call forwarding on No Answer 


7.4.11.4.12 [18] 


M 


M 


1 


Call forwarding on Busy 
subscriber 


7.4.11.4.13 [18] 


M 


M 


1 


NG1.N.17 Calling line identity 
restriction 




5.2 [18] 


M 


M 





Considerations 


7.4.12.1 [18] 


M 


M 





Permanent CLIR mode (all calls) 


7.4.12.2 [18] 


M 


M 





Temporary CLIR mode (call by call) 


7.4.12.3 [18] 


M 


N/A 





NG1.N.18 Call forwarding 
(external calls) 




5.2 [18] 


M 


M 


1 


Call Forwarding common 
requirements 


7.4.13.1 [18] 


M 


M 


1 
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External Call Forwarding 
Unconditional (CFU) to external 
number 


7.4.13.2 [18] 


M 


M 


1 


External Call Forwarding on No 
Answer (CFNA) to external number 


7.4.13.3 [18] 


M 


M 


1 


External Call Forwarding on Busy 
subscriber (CFB) to external 
number 


7.4.13.4 [18] 


M 


M 


1 


NG1.N.19DTMF handling 




5.2(18] 


M 


M 





Uplink DTMF transmission at call 
setup when FP connected to 
classic switching network 


7.4.14.1.1 [18] 


M 


C906 


C906 


Uplink DTMF transmission when 
connected 


7.4.14.1.2 [18] 


M 


M 





Downlink DTMF reception 


7.4.14.2 [18] 


M 


M 





Local DTMF feedback of dialled 
digits 


7.4.14.3 [18] 


M 


M 





NG1 .N.20 Tones provision 




5.2 [18] 


M 


M 





General considerations 


7.4.15.1 [18] 


M 


M 





Tones provision by the system 


7.4.15.2 [18] 


M 


M 





Transparency to tones provision by 
the network or PABX 


7.4.15.3 [18] 


M 


M 





NG1.N.21 Headset management 




5.2 [18] 


C907 


M 





Headset considerations 


7.4.16.1 [18] 


C907 


M 





Headset call interception 


7.4.16.2 [18] 


C907 


M 





Headset incoming call 


7.4.16.3 [18] 


C907 


M 





Re-dial of last outgoing call 


7.4.16.4 [18] 


C908 


M 





Re-dial of last incoming call 


7.4.16.5 [18] 


C908 


M 





Switching from headset to handset 
(headset initiated) 


7.4.16.6 [18] 


C908 


M 





Switching from headset to handset 
(handset initiated) 


7.4.16.7 [18] 


C909 


M 





Compatibility with other telephony 
features and profiles 


7.4.16.8 [18] 


C907 


M 





NG1 .N.22 Handling of lines where 
second calls are signalled in-band 




5.2 [18] 


M 




(note 2) 





General requirements 


7.4.3.10.1 [18] 


1 


M 


M 


Basic 'double call with in-band 
signalling' lines 


7.4.3.10.2 [18] 


1 


M 
(note 3) 


M 


Off-hook CLIP enabled 'double call 
with in-band signalling' lines 


7.4.3.10.3 [18] 


M 


M 
(note 3) 


M 


Use of transparent commands on 
DCIBS lines (Basic or Off-hook 
CLIP enabled) or any other line 


7.4.3.10.4 [18] 


M 


M 


M 



£75/ 



39 



ETSI TS 102 527-5 V1.1.1 (2013-04) 



Feature/Procedure mapping 




Status 1 


Feature 


Procedure 


Reference 


PT 


FT 1 


R/B 


P 


NG1.N.23 Line and diagnostic 
information 




5.2 


M 


M 





Generic events notification, general 


7.4.1.1 [18] 


M 


M 





General requirements 


7.4.34.1 


M 


M 







Exposed diagnostic information 


7.4.34.2 


M 


M 







Line and Diagnostic Statuses List 


7.4.34.3 


M 


M 







Line and Diagnostic Statuses List 
details 

'OK status' (one status per line) 

'Line use status' (one status per 
line) 

'Handset use status' (one status 

per line) 

'Call Forwarding status' (3 

statuses per line) 

'Diagnostic error status', 

- line related (1 status per line) 

- non-line related (1 st. for 
system) 


7.4.34.3.2 
7.4.34.3.3 
7.4.34.3.4 

7.4.34.3.5 

7.4.34.3.6 
7.4.34.3.6 


M 

M 
M 


M 

M 
M 


M 

M 
M 
M 

M 

M 
M 
















Diagnostic indication 


7.4.1.5 


M 


M 





NG1 .N.24 Short IVIessage Service 




5.2 











General requirements 


7.4.35.1 


M 


M 


M 


Incoming SMS handling 


7.4.35.2 


M 


M 


M 


Outgoing SMS handling 


7.4.35.3 


M 


M 


M 


SMS settings 


7.4.35.4 


M 


M 


M 


SMS related entry fields and lists 


7.4.35.5 


M 


M 


M 


NG1.N.25 Digital Telephone 
Answering Machine 




5.2 











Voice Message waiting notification 


7.4.1.2 


M 


M 


M 


List access service 


7.4.10 


M 


M 


M 


DTAM General description 


7.4.36.1 


M 


M 


M 


Voice oriented DTAM 


7.4.36.2.1 


C914 


C914 


C914 


Visual DTAM 


7.4.36.2.2 


C914 


C914 


C914 


DTAM consulting call 


7.4.36.3 


M 


M 


M 


DTAM Commands 


7.4.36.4 


M 


M 


M 


DTAM specific fields description 


7.4.36.5.1 


M 


M 


M 


DTAM Settings List 


7.4.36.5.2 


M 


M 


M 


DTAM Incoming Calls List 


7.4.36.5.3 


C915 


C915 


C915 


DTAM Welcome Message List 


7.4.36.5.4 


M 


M 


M 


List Access service call 
transformation into a DTAM 
consulting call 


7.4.36.5.5 


M 


M 


M 


NG1.N.26 Call screening 




5.2 













Screening general requirements 


7.4.36.6.1 


M 


M 


M 




Call screening indication (FP to 
PP) 


7.4.36.6.2 


M 


M 


M 




Call screening acceptance (PP to 
FP) 


7.4.36.6.3 


M 


M 


M 




Call screening rejection (PP to FP) 


7.4.36.6.4 


M 


M 


M 




Call screening interception (PP to 
FP) 


7.4.36.6.5 


M 


M 


M 




FP initiated call screening release 
(FPtoPP) 


7.4.36.6.6 


M 


M 


M 




Parallel call during active call 
screening 


7.4.36.6.7 


M 


M 


M 




Call screening of a waiting call 


7.4.36.6.8 


M 


M 


M 




Call screening with screening and 
non-screening PPs 


7.4.36.6.9 


M 


M 


M 




Single/Multiple PP(s) call screening 
mode 


7.4.36.6.10 


M 


M 


M 


GAP. N.I Outgoing call 




4.1 [111 


M 


M 


M 


Outgoing call request 


8.2(11] 


M 


M 


M 


Overlap sending 


8.3 [11] 


M 
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Outgoing call proceeding 


8.4 [11] 


M 








Outgoing call confirmation 


8.5 [11] 


M 








Outgoing call connection 


8.6(11] 


M 


M 


M 


Sending keypad information 


8.10[11] 


M 


M 


M 


Abnormal release in case of call 
setup collisions 


9.5.2.3 [5] 


M 


M 


M 


Contact number and name 
matching on outgoing call 


7.4.32 


M 


M 





GAP.N.8 Incoming call 




4.1 [11] 


M 


M 


M 


Incoming call request 


8.12[11] 


M 


M 


M 


Incoming call confirmation 


8.13 [11] 


M 


M 


M 


PT alerting 


8.14[11] 


M 


M 


M 


Incoming call connection 


8.15(11] 


M 


M 


M 


Abnormal release in case of call 
setup collisions 


9.5.2.3 [5] 


M 


M 


M 


GAP. N. 11 Location registration 




4.1 [11] 


M 





M 


Location registration 


8.28 [11] 


M 


M 


M 


Location update 


8.29 [11] 


M 








Terminal Capability indication 


7.4.9.1 


M 


M 


M 




Location registration after re-lock 


7.4.18 


M 


N/A 


N/A 


GAP.N.14 Service class 
indication/assignment 




4.1 [11] 


M 





M 


Obtaining access rights 


8.30 [11] 


M 


M 


M 


Terminal Capability indication 


7.4.9.1 


M 


M 


M 


Authentication of PP using DSAA 


8.24 [11] 


M 


M 


M 


Authentication of PP using DSAA2 


8.45.7(11] 


C910 


C910 


C910 


GAP. N. 16 ZAP 




4.1(11] 


M 








Obtaining access rights 


8.30(11] 


M 


M 


M 


Terminal Capability indication 


7.4.9.1 


M 


M 


M 


Incrementing the ZAP value 


8.26(11] 


M 


M 


M 


Authentication of FT using DSAA 


8.23(11] 





M 


M 




Authentication of FT using DSAA2 


8.45.6(11] 


C911 


C910 


C910 


GAP. N.I 8 Subscription 
registration user procedure on-air 




4.1(11] 


M 


M 


M 


Obtaining access rights 


8.30(11] 


M 


M 


M 


Terminal Capability indication 


7.4.9.1 


M 


M 


M 


GAP. N.I 9 Link control 




4.1(11] 


M 


M 


M 


Indirect FT initiated link 
establishment 


7.3.8(17] 


M 


M 


M 


Direct PT initiated link 
establishment 


8.36(11] 


M 


M 


M 


Link release "normal" 


8.37(11] 


M 


M 


M 


Link release "abnormal" 


8.38(11] 


M 


M 


M 


Link release "maintain" 


8.39(11] 


M 


M 


M 


GAP. N. 24 Signalling of display 
characters 




4.1(11] 











Display 


8.16(11] 


M 


M 


M 


Terminal capability indication 


7.4.9.1 


M 


M 


M 


GAP.N.25 Display control 
characters 




4.1 [11] 











Display 


8.16(11] 


M 


M 


M 


Terminal capability indication 


7.4.9.1 


M 


M 


M 


GAP.N.31 Internal Call 




4.1(11] 


M 


M 


M 


Internal call setup 


7.3.6(17] 


M 


M 


M 


Internal call keypad 


8.19(11] 


M 








Internal call CLIP 


8.43(11] 


M 


M 


M 


Internal call CNIP 


8.44(11] 


M 


M 


M 


Internal call codec priority 


7.4.3.9(18] 


M 


M 


M 


UTF-8 CNIP 


7.4.17(18] 


M 


M 


M 


GAP. N.34 Calling Name 
Identification Presentation (CNIP) 




4.1(11] 


M 


M 


M 


Calling Name Identification 
Presentation (CNIP) Indication 


8.42(11] 


M 


M 


M 


UTF-8 CNIP 


7.4.17(18] 


M 


M 


M 
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Contact number and name 
matching on incoming call 


7.4.33 


M 


M 


M 


GAP. N. 35 Enhanced security 




4.1 [11] 


M 


M 


M 


Encryption of all calls 


8.45.1 [11] 


M 


M 


M 


Re-keying during a call 


8.45.2 [11] 


M 


M 


M 


Early encryption 


8.45.3(11] 


M 


M 


M 


Subscription requirements 


8.45.4 [11] 


M 


M 


M 


Behaviour against legacy devices 


8.45.5 [11] 


M 


M 


M 


C901 
C902 
C903 
C904 
C905 
C906 
C907 
C908 
C909 
C910 
C911 
C912 
C913 
C914 
C915 
C916 
C917 


At least one of the two procedures 7.4.3.8.1 OR 7.4.3.8.2 shall be implemented. 

IF NG1 .N.14 THEN "0" ELSE "1". 

IF NG1 .M.5 THEN "M" ELSE "1". 

IF NG1 .N.10 THEN "M" ELSE "1". 

IF NG1 .N.17 THEN "M" ELSE "1". 

IF FP is connected to classic switching networks (PSTN for example) THEN "M" ELSE "N/A". 

IF the PT is a headset PP THEN "M" ELSE "1". 

IF the PT is a headset PP THEN "0" ELSE "1". 

IF the PT is a headset PP THEN "1" ELSE "0". 

IF feature GAP.N.36 THEN M ELSE 1. 

IF feature GAP.N.36 THEN ELSE 1. 

IF NG1.N.24 (Short Message Service) THEN "M" ELSE "1". 

IF NG1.N.24 (Short Message Service) THEN "0" ELSE "1". 

IF NG1.N.25 (DTAM) THEN "M" ELSE "1". 

IF NG1 .N.25 (DTAM) and Visual DTAM implemented THEN "M" ELSE IF NG1 .N.25 THEN "0" ELSE 1. 

At least one of the two procedures 7.4.36.2.1 OR 7.4.36.2.2 shall be implemented. 

IF Visual DTAM implemented THEN "M" ELSE "0". 


NOTE 1 : If the corresponding feature is not supported on FT side, the FT shall however implement the "sending 

negative acknowledgement" procedure (see 7.4.3.4 of [18]). 
NOTE 2: All procedures of NG1 .N.6 and NG1 .N.7 shall apply to all FTs and for all line types (full parallel call 

compliant lines and DCIBS lines). For DCIBS lines, the FT shall implement in addition NG1 .N.22 

feature, which describes some amendments to NG1 .N.6 and NG1 .N.7 for such lines. A given FT shall 

be designed to handle both line types, or only one of them. 
NOTE 3: Both procedures are M for the FP. However, for a given line, only one of the procedures 7.4.3.1 0.2 or 

7.4.3.10.3 of [18] is used. 
NOTE 4: See also clause 7.4.10.4 for details per list. 

NOTE 5: This procedure is provisioned for GAP and Part 1 PPs and is irrelevant for Part 3 and Part 5 PPs. 
NOTE 6: The procedure "Resuming a call put on-hold" is optional for the PP. However the corresponding control 

message is mandatory for PPs since it may be needed by the call release procedure (see 

clause 7.4.3.5.4). 
NOTE 7: Some DTAIVIs may not support the DTAM incoming calls list, even if the PP and FP support it. See 

clause 7.4.36.2.1. 
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6.1 1 Data Link Control (DLC) Service to procedure mapping 

The DLC service to procedure mapping of EN 300 444 [11] (GAP), clause 6.8.1, with the following changes and 
additional services shall apply. 

Table 10: DLC service to procedure mapping 



Service/Procedure mapping 




Status 1 


Service 


Procedure 


Reference 


PT 


FT 1 


R/B 


P 


NG1.D.1 LU1 Transparent 
Unprotected service (TRUP) 
Class 0/minimum_delay 




5.3 [11] 


M 


M 


M 


LU1 Transparent Unprotected service 
(TRUP) operation 


11.2 [4] 


M 


M 


M 


Class 0: No Lux retransmission or 
sequencing 


14.2.3.1 [4] 


M 


M 


M 


Class procedures 


14.3.2 [4] 


M 


M 


M 


IVIinimum delay (speech) operation 


14.2.3(4] 


M 


M 


M 


LLIVIE U-plane establishment 


9.9.1 [11] 


M 


M 


M 


NG1.D.2LU1 Transparent 
Unprotected service (TRUP) 
Class 




5.3 [17] 


C1001 


C1001 


C1001 


LU1 Transparent Unprotected service 
(TRUP) operation 


11.2 [4] 


M 


M 


M 


Class 0: No Lux retransmission or 
sequencing 


14.2.3.1 [4] 


M 


M 


M 


Class procedures 


14.3.2 [4] 


M 


M 


M 


LLME U-plane establishment 


9.9.1 [11] 


M 


M 


M 


NG1 .D.3 LU7 64 kbit/s protected 
bearer service 




5.3 [17] 


C1001 


C1001 


C1001 


LU7 DLC layer service 


11.9.4(4] 


M 


M 


M 


NG1.D.4LU 12 Unprotected 
Framed service (UNF) Class 




5.3 [11] 


C1001 


C1001 


C1001 


LU12 UNprotected Framed service (UNF) 
operation 


11.14 [4] 


M 


M 


M 


Class 0: No Lux retransmission or 
sequencing 


14.2.3.1 [4] 


M 


M 


M 


Class procedures 


14.3.2 [4] 


M 


M 


M 


LLIVIE U-plane establishment 


9.9.1 [11] 


M 


M 


M 


NG1.D.5FU1 DLC frame 




5.3 [11] 


M 


M 


M 


FU1 frame operation 


8.19(11] 


M 


M 


M 


FU1 frame structure 


12.2 [4] 


M 


M 


M 


NG1.D.6FU7 DLC frame 




5.3 [11] 


C1001 


C1001 


C1001 


FU7 frame structure 


11.9.4.2(4] 


M 


M 


M 


NG1 .D.7 FU1 2 DLC frame with 
adaptation for codec G.729.1 




5.3 [11] 


CI 001 


C1001 


C1001 


FU12 frame structure 


12.12(4] 


M 


M 


M 


Annex for codec G.729.1 


E.I [4] 


M 


M 


M 


FU12frame operation 


7.5.2(11] 


M 


M 


M 


C1 001 : Status defined by clause 6.3, table 2. 
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6.12 Medium Access Control (MAC) service to procedure 
mapping 

The MAC service to procedure mapping of EN 300 444 (GAP) [11], clause 6.8.2, with the following changes and 
additional services shall apply. 

Table 11 : MAC service to procedure mapping 



Service/Procedure mapping 




Status 1 


Service 


Procedure 


Reference 


PT 


FT 1 


R/B 


P 


NG1.M.1 lN_minimum delay 
symmetric MAC service type 




5.4 [17] 


M 


M 


M 


MAC layer procedures: general 


7.9.1 [17] 


M 


M 


M 


MAC Connection oriented service 


5.6 [3] 


M 


M 


M 


MAC Basic connection 


5.6.1.1 [3] 


M 


M 


M 


MAC Advanced connection 


5.6.1.2 [3] 


M 


M 


M 


lN_minimum delay symmetric MAC service, 
type 1 


5.6.2.1 [3] 


M 


M 


M 


NG1.I\/I.2 lN_normal delay 
symmetric MAC service type 




5.4 [17] 











MAC layer procedures: general 


7.9.1 [17] 


M 


M 


M 


MAC Connection oriented service 


5.6 [3] 


M 


M 


M 


MAC Basic connection 


5.6.1.1 [3] 


M 


M 


M 


MAC Advanced connection 


5.6.1.2 [3] 


M 


M 


M 


lN_normal delay symmetric MAC service 
type 2 


5.6.2.1 [3] 


M 


M 


M 


NG1.M.3 lpQ_error_detection 
symmetric MAC service type 




5.4 [17] 











MAC layer procedures: general 


7.9.1 [17] 


M 


M 


M 


MAC Connection oriented service 


5.6 [3] 


M 


M 


M 


MAC Basic connection 


5.6.1.1 [3] 


M 


M 


M 


MAC Advanced connection 


5.6.1.2 [3] 


M 


M 


M 


lp_error_detection symmetric MAC service 
types 


5.6.2.1 [3] 


M 


M 


M 


Single-subfield protected format 


6.2.1.3.4 [3] 


M 


M 


M 
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Service/Procedure mapping 




Status 1 


Service 


Procedure 


Reference 


PT 


FT 1 


R/B 


P 


NG1 .M.4 Advanced connections 




5.4 [17] 


M 


M 


M 


Setup of advanced connection, bearer 
setup (A-field) 


7.6.5 [17] 


M 


M 


M 


Connection type modification: basic to/from 
advanced 


7.6.6 [17] 


M 


M 


M 


Slot type modification 


7.6.7 [17] 


M 


M 


M 


Service type modification 


7.6.8 [17] 


C1101 


C1101 


C1101 


ECN number modification 


7.6.9 [17] 


C1 102 


C1 102 


C1 102 


Connection/bearer release 


7.6.10 [17] 


M 


M 


M 


NG1 .M.5 "no-emission" mode 




5.4 [18] 











Tail identification for "no emission" mode 


7.1.2 [3] 


M 


M 


M 


Extended Physical and Mac layer 
capabilities (part 2) bit a23 


7.2.3.11 [3] 


M 


M 


M 


Bearer handover/replacement information, 
multiframe-countdown 


7.2.4.3 [3] 


M 


M 


M 


"no emission" mode sync information 


7.3.5.3 [3] 


M 


M 


M 


"no emission" mode procedures 


9.4 [3] 


M 


M 


M 


Management procedures for "no emission" 
mode 


11.11 [3] 


M 


M 


M 


NGLIVI.e "low duty cycle 
Idle Locked" mode 




5.4 [3] 











GAP.M.2 Continuous broadcast 




5.2 [11] 


M 


M 


M 


Downlink broadcast 


7.6.3 


M 


M 


M 


Higher Layer information FP broadcast 


7.4.9.2 


M 


M 


M 


GAP.IVI.3 Paging broadcast 




5.2 [11] 


M 


M 


M 


Paging broadcast 


7.6.4 [17] 


M 


M 


M 












GAP.IVI.9 Bearer handover, intra- 
cell 




5.2 [11] 


M 


C1 103 


C1 103 


Bearer handover request 


7.6.11 [17] 


M 


M 


M 


GAP. M. 10 Bearer handover, 
inter-cell 




5.2 [11] 


M 








Bearer handover request 


7.6.11 [17] 


M 


M 


M 


GAP.IVI.11 Connection handover, 
intra-cell 




5.2 [11] 


M 


C1 104 


C1 104 


Connection handover request 


7.6.12(17] 


M 


M 


M 


GAP. M. 12 Connection handover, 
inter-cell 




5.2 [11] 


M 








Connection handover request 


7.6.12(17] 


M 


M 


M 


GAP. M.I 3 SARI support 




5.2 [11] 


M 








Downlink broadcast 


7.6.3 


M 


M 


M 


Higher Layer information FP broadcast 


7.4.9.2 


M 


M 


M 


GAP.IVI.15 Re-keying 




5.2 [11] 


M 


M 


M 


Re-keying 


10.17(11] 


M 


M 


M 


GAP.IVI.16 Early encryption 




5.2(11] 


M 


M 


M 


Early encryption 


10.18(11] 


M 


M 


M 


C1101 
C1 102 
C1 103 
C1 104 


IF service NG1 .4 OR NG1 .5 OR NG1 .6 OR NG1 .2 lA II OR NG1 .2 lA III THEN M ELSE 0. 
IF multiple connection between the same PT-FT pair THEN M ELSE 0. 
IF service GAP.M.1 1 THEN ELSE M. 
IF service GAP.M.9 THEN ELSE M. 
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6.13 Application feature to procedure mapping 

The Application feature to procedure mapping of EN 300 444 [11] (GAP), clause 6.8.3, with the following changes 
shall apply. 

Table 12: Application feature to procedure mapping 



Feature/Procedure mapping 




Status 1 


Feature 


Procedure 


Reference 


PT 


FT 1 


R/B 


P 


NG1.A.1 Easy PIN code 
registration 




5.7 [18] 


M 





N/A 


Registration mode automatic access 


7.10.1.3.1 
[181 


M 


N/A 


N/A 


Searching mode and PIN code requests 


7.10.1.1.1 
[18] 


M 


N/A 


N/A 


Base station name selection 


7.10.1.3.2 
[18] 








N/A 


Registration user feedback 


7.10.1.3.3 
[18] 


M 





N/A 


NG1 .A.2 Easy pairing registration 




5.7(18] 


M 


M 


N/A 


Easy pairing description 


7.10.1.2.1 
[18] 


M 


M 


N/A 


Registration mode automatic access 


7.10.1.3.1 
[18] 


M 


N/A 


N/A 


Base station limited registration mode 


7.10.1.2.2 
[18] 


N/A 


M 


N/A 


Searching mode request 


7.10.1.2.3 
[18] 


M 


N/A 


N/A 


Base station name selection 


7.10.1.3.2 
[18] 





M 


N/A 


Registration user feedback 


7.10.1.3.3 
[18] 


M 





N/A 


NG1 .A.3 Handset locator 




5.7 [18] 


M 








Handset locator 


7.10.2(18] 


M 


M 





NG1 .A.5 Base manual transmit 
power control 




5.7 


N/A 


M 





Base manual transmit power control 


7.10.3.1 


N/A 


M 





NG1 .A.6 Handset adaptive 
transmit power control 




5.7 


M 


N/A 


N/A 


Handset adaptive transmit power control 


7.10.3.2 


M 


N/A 


N/A 


GAP.A.1 AC to bitstring mapping 




4.2 [11] 


M 


C1201 


M 


AG to bitstring mapping 


14.2 [11] 


M 


M 


M 


GAP. A. 2 IVIultiple subscription 
registration 




4.2(11] 


M 


N/A 


N/A 


Subscription control 


14.1 [11] 


M 


N/A 


N/A 


GAP.A.3 Manual entry of the 
PARK 




4.2(11] 





N/A 


N/A 


Manual entry of the PARK 


14.3 [11] 


M 


N/A 


N/A 


GAP. A. 4 Terminal identity number 
assignment in mono cell system 




4.2(11] 


M 


M 


N/A 


Terminal identity number assignment 


14.4 [11] 


M 


M 


N/A 


01201: IF feature GAP. N.9 OR 


GAP.N.10 OR GAP.N.12 OR GAP.N.26 Th 


lEN M ELSE 


N/A. 







6.14 General requirements 

6.1 4.1 Network (NWK) layer message contents 

The requirements of TS 102 527-1 [17], clause 6.14.1 shall apply. 

6.14.2 Transaction identifier 

The requirements of TS 102 527-1 [17], clause 6.14.2 shall apply. 
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6.1 4.3 Length of a Network (NWK) layer message 

The requirements of TS 102 527-1 [17], clause 6.14.3 shall apply. 

6.1 4.4 Handling of error and exception conditions 

The requirements of TS 102 527-1 [17], clause 6.14.4 shall apply. 

6.1 4.5 Generic Access Profile (GAP) default setup attributes 

The requirements of TS 102 527-1 [17], clause 6.14.5 shall apply. 

6.14.6 Coexistence of Mobility Management (MM) and Call Control (CC) 
procedures 

The requirements of TS 102 527-1 [17], clause 6.14.6 shall apply. 

6.1 4.7 Coding rules for information elements 

The requirements of TS 102 527-1 [17], clause 6.14.7 shall apply. 



7 Procedure description 



The following clauses define the process mandatory procedures which are in the scope of the "New Generation DECT; 
Part 5: Additional feature set nr. 1 for extended wideband speech services". Each procedure (if appropriate) is divided 
into three parts: 

a) Normal (i.e. successful) case(s). This part defines the functions and respective protocol element values in 
normal operation. 

b) Associated procedure(s). This is an integral part of the actual procedure (if defined in the present document), 
i.e. if a procedure is being declared to be supported, the respective entity shall also support the associated 
procedures, e.g. timer management, in the clause following the description of the normal case. 

c) Exceptional case(s). This is an integral part of the actual procedure (if defined in the present document), i.e. if 
a procedure is being declared to be supported, the respective entity shall also support the exception handling 
defined in the clause following the description of the normal case. 

All protocol elements listed in the following clauses are process mandatory, i.e. the FT and PT depending on their role 
in the procedure shall send or shall receive and process the relevant protocol elements as listed in the respective tables if 
not explicitly stated as being optional. 

The primitives used in procedure descriptions are defined only for the purpose of describing layer-to-layer interactions. 
The primitives are defined as an abstract list of parameters, and their concrete realization may vary between 
implementations. No formal testing of primitives is intended. The primitive definitions have no normative significance. 
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7.1 Backward compatibility with Generic Access Profile (GAP), 
New Generation DECT part 1 (wideband speech) and with 
New Generation DECT part 3 (extended wideband speech 
services) equipment 

7.1 .1 Backward compatibility with Generic Access Profile (GAP); 
Requirements for NG-DECT, part 5 Fixed Parts (FPs) 

The FP shall support the GAP (EN 300 444 [11]) standard procedures (full slot and 

Recommendation ITU-T G.726 [12]). In other words, it shall inter-operate with a GAP compliant PP. The use of 

messages or information elements not known to GAP PPs is not recommended. 

NOTE 1 : The FP may detect the type of PP by means of the Information Element <Terminal Capability> provided 
at registration. 

NOTE 2: It should be noted that GAP compliant PPs may have a more relaxed requirement of TCLw than New 
Generation DECT part 3 devices. In some scenarios, when combining GAP terminals with poor TCLw 
with long delay networks (like VoIP) and insufficient echo cancellation in the network, audible echo 
could be perceived by the far end terminal. This problem is not specific of devices compliant with the 
present document. For more information refer to EN 300 175-8 [8], annex E. 

7.1 .2 Backward compatibility with Generic Access Profile (GAP); 
Requirements for NG-DECT, part 5 Portable Parts (PPs) registered 
on GAP compliant FPs 

The PP shall use the GAP standard procedures and voice codec (full slot and Recommendation ITU-T G.726 [12]) 
when registered in a GAP Fixed Part. In other words, it shall inter-operate with a GAP compliant FP. The use of 
messages or information elements not known to GAP FPs is not recommended. 

NOTE: The PP may detect the type of FP by observing the higher layer capabilities information broadcasted by 
the FP. 

7.1 .3 Backward compatibility with New Generation DECT, part 1 ; 
Requirements for NG-DECT, part 5 Fixed Parts (FPs) 

The FP shall support DECT New Generation part 1 (TS 102 527-1 [17]) procedures. In other words, a DECT New 
Generation, part 5 Fixed part shall operate exactly as a DECT New Generation, part 1 FP for a New Generation Part 1 
PP. All features and services defined in TS 102 527-1 [17] shall be provided. The use of messages or information 
elements not known to New Generation DECT Part 1 PPs is not recommended. 

NOTE 1 : The FP may detect the type of PP by means of the Information Element <Terminal Capability> provided 
at registration. 

NOTE 2: It should be noted that New Generation DECT part 1 PPs may have a more relaxed requirement of TCLw 
than New Generation DECT part 3 and part 5 devices. Note 2 of clause 7.1.1 of [18] may be also 
applicable this case. For more information refer to EN 300 175-8 [8], annex E. 

7.1 .4 Backward compatibility with New Generation DECT, part 1 ; 
Requirements for NG-DECT, part 5 Portable Parts (PPs) registered 
on NG-DECT part 1 FPs 

The PP shall use the part 1 standard procedures (TS 102 527-1 [17]) when registered in a NG-DECT part 1 Fixed Part. 
In other words, it shall inter-operate with a New Generation DECT Part 1 compliant FP. The use of messages or 
information elements not known to New Generation DECT Part 1 FPs is not recommended. 
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NOTE: The PP may detect the type of FP by observing the higher layer capabihties information broadcasted by 
the FP. 

7.1 .5 Backward compatibility witin New Generation DECT, part 3; 
Requirements for NG-DECT, part 5 Fixed Parts (FPs) 

The FP shall support DECT New Generation part 3 (TS 102 527-3 [18]) procedures. In other words, a DECT New 
Generation, part 5 Fixed Part shall operate exactly as a DECT New Generation, part 3 FP for a New Generation Part 3 
PP. All features and services defined in TS 102 527-3 [18] shall be provided. The use of messages or information 
elements not known to New Generation DECT Part 3 PPs is not recommended. 

NOTE 1 : The FP may detect the type of PP by means of the Information Element <Terminal Capability> provided 
at registration. 

NOTE 2: New Generation DECT part 3 PPs have similar requirements of TCLw than New Generation DECT 
part 5 devices. 

7.1 .6 Backward compatibility with New Generation DECT, part 3; 
Requirements for NG-DECT, part 5 Portable Parts (PPs) registered 
on NG-DECT part 3 FPs 

The PP shall use the part 3 standard procedures (TS 102 527-3 [18]) when registered in a NG-DECT part 3 Fixed Part. 
In other words, it shall inter-operate with a New Generation DECT Part 3 compliant FP. The use of messages or 
information elements not known to New Generation DECT Part 3 FPs is not recommended. 

NOTE: The PP may detect the type of FP by observing the higher layer capabilities information broadcasted by 
theFP. 

7.2 Generic Access Profile (GAP) procedures 

Unless otherwise noted, all procedures defined in EN 300 444 [11] GAP apply. Therefore the present document can be 
considered an extension of GAP. 

7.3 New Generation DECT; part 1 : Wideband Speech and New 
Generation DECT; part 3: Extended Wideband Speech 
Services procedures 

The present document is defined as an extension of New Generation DECT; part 3: Extended Wideband Speech 
Services [18], which is itself an extension of New Generation DECT; part 1: Wideband Speech [17]. 

Unless otherwise noted, all procedures defined in TS 102 527-3 [18] (New Generation DECT; part 3: Extended 
Wideband Speech Services) are automatically applicable to New Generation DECT; part 5: Additional feature set nr. 1 
for extended wideband speech services. 

Unless otherwise noted, all procedures defined in TS 102 527-1 [17] (New Generation DECT; part 1: Wideband 
Speech) are automatically applicable to New Generation DECT; part 5: Additional feature set nr. 1 for extended 
wideband speech services. 

The clauses 7.4 to 7.10 describe the additional procedures specific for New Generation DECT; part 5: Additional 
feature set nr. 1 for extended wideband speech services. 

7.3.1 Implementation examples of part 1 : Wideband Speech specific 
procedures 

For detailed examples of Wideband speech specific procedures, please refer to the informative annex D of 
TS 102 527-1 [17]. 
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7.3.2 Implementation examples of part 3: Extended Wideband Speech 
Services specific procedures 

For detailed examples of part 3: Extended Wideband Speech Services specific procedures, please refer to the 
informative annex C of TS 102 527-3 [18]. See also the normative annex B of the same document for Events 
Notification, Date-Time synchronization and List Access Service procedures. 

7.4 Network (NWK) layer procedures specific to part 5 

This clause specifies the additional NWK layer procedures, messages and information elements required in "New 
Generation DECT; Part 5:Additional feature set nr. 1 for extended wideband speech services" not described in 
TS 102 527-3 [18], TS 102 527-1 [17] or in EN 300 444 [11] (GAP), or incorporating modifications to the descriptions 
given in these specifications. 

This profile does not prevent any PT or FT from transmitting or receiving and processing any other NWK layer 
message or information element not specified in the profile. A PT or FT receiving an unsupported NWK layer message 
or information element, which it does not recognize, shall ignore it, as specified in EN 300 175-5 [5], clause 17. 

The following conventions have been used for the numeration of the subclauses in this clause of the present document: 

• Subclauses describing procedures that are a modification of similar procedures described in TS 102 527-3 [18] 
have received the same subclause number. 

• Descriptions of new procedures specific to the present document, start at clause 7.4.32. This leaves room 
before clause 7.4.32 for features and procedures that may be designed in the future but which are not specific 
to Part 5, that is, which apply to both Part 3 and Part 5, because they are considered important to both parts. As 
a result, all non Part 5 specific features and procedures will not be interleaved with Part 5 specific ones and 
will be in contiguous subclauses. 

• Subclause numbers of procedures that are described in TS 102 527-3 [18] (Part 3) and are not modified by the 
present document are not re-used and when present just refer the reader to the corresponding procedure in 
Part 3. 

NOTE: Unmodified clauses whose parent clause is itself not modified by the present document are absent. 

7.4.1 Generic events notification 

7.4.1.1 General 

All mandatory requirements as defined in clause 7.4.1.1 of TS 102 527-3 [18] shall apply. 

7.4.1 .2 Voice Message waiting notification 

All mandatory requirements as defined in clause 7.4.1.2 of TS 102 527-3 [18] shall apply. 

7.4.1.3 Missed call notifications 

All mandatory requirements as defined in clause 7.4.1.3 of TS 102 527-3 [18] shall apply, with the following addition: 

Extended notification: If extended notifications are used (see 7.4.10.7.1), the above requirements still apply, in 
addition to the requirements of clause 7.4.10.7. In particular an additional «List change details» IE may be used in 
the same message. 

7.4.1 .4 List change notification 

See "List access service", list change notification procedure (see clause 7.4.10.2) for the detailed behaviour. 
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7.4.1 .5 Line and diagnostic statuses notifications 

7.4.1.5.1 General requirements 

One or more indication(s) are sent by the FP each time an event modifies the 'Line and diagnostic statuses' list for 
notifying the changes to the PPs. Depending on the type of event (and related modification within the 'Line and 
diagnostic statuses' list) one or several indications are sent from the FP to the PPs (see clause 7.4. L5. 2 for details). 

Indication: Indications are special types of generic events notification and are sent in an «Events Notification» IE 
(see EN 300 175-5 [5], clause 7.7.55). For the purpose of the 'Line and diagnostic information' feature, three types of 
indications are defined below. 

Notification: An «Events notification» IE may contain several indications, of the same or of different types. The 
term 'notification' is therefore reserved in the following text for the set of indications sent together in an «E vents 
notification» IE (possibly a single one). 

Line relating event: An event may or not relate to a specific line. The <Event multiplicity> field of the indications is 
used to indicate the line on which the change occurred. If the change does not related to any specific line, the <Event 
multiplicity> field holds a don't care value. 

NOTE: For indication types allowing line related and non line related indications (i.e. diagnostic indications), the 
<event subtype> field indicates whether the indication is line related or not. 

Indication types: There are three types of indications: 

'line use status' indication (always 'line related') 

'handset use status' indication (always 'line related') 

'diagnostic' indication (line related or not, depending on the case); a 'diagnostic' indication relates to the 
working status of a line or of the system. Apart from the line where it happens (if any), the diagnostic 
indication itself does not indicate any diagnostic details. 

NOTE 1 : Typically, an 'external call setup' or 'external call release' event could either generate both a 'line use 
status' and a 'handset use status' indications, or only one of them, or even none of them. 

EXAMPLE: If a handset already involved in a call on a multiple call line sets up another parallel call on the 
same line, one of the two situations could occur: 

- if the line and FP would support a third call, no indication is sent to the PPs (line use and handset 
use statuses do not change). 

- if the line or system supports only two calls, a line use status indication is sent, as the line or 
system is becoming busy. 

NOTE 2: List change indications are not used for the 'Line and diagnostic statuses' list, and are replaced with line 
use status, handset use status and diagnostic indications. Therefore clause 7.4.10.2, 'List change 
notification' is irrelevant for this list. 

A line use status, handset use status and/or a diagnostic indication is sent from the FP to the PP each time a status 
change occurs on FP side resulting in an update of the 'Line and diagnostic statuses' list (e.g. a change of the 'Line OK' 
or 'Line use' status, a change of the call forwarding settings etc.). 

NOTE 3: However, some status changes in the Line and Diagnostic Statuses List are not notified. See 
clause 7.4.1.5.2 for details. 

New status value: As a general rule, the line and diagnostic indications do not contain the new status value but only 
notifies the status change. If the PP wants to get information about the new status value, it has to perform a List Access 
to the 'Line and diagnostic status' list. 

Line use status value: As an exception to this general rule, a 'line use status' indication shall always contain the current 
'Line use' status value. 

The contained 'Line use' status value shall always reflect the current use status of the line. This avoids the PP needing to 
access the 'Line and diagnostic statuses' list for retrieving this frequently changing status value. 



£75/ 



51 ETSI TS 1 02 527-5 V1 .1 .1 (201 3-04) 

Targeted PPs: The targeted PPs is the set of PPs receiving the notification. The set of targeted PPs depends on the type 
of event triggering the notifications and is described in the next clause. For a Hne related change, at least the PP(s) 
attached to the line(s) on which the change(s) occurred shall be notified by the FP. 

Aggregation of indications of almost simultaneous events: If successive indications of the same type (and relating to 
the same line if line related) are about to be sent in order to notify successive but almost simultaneous changes, it is 
allowed to send only the last indication. 

Conversely, indications of the same type and relating to the same line — if line related — that are sent separately (i.e. that 
are not aggregated) cannot be sent in the same «Events-notification» IE: in that case, different {FACILITY} 
messages shall be used. 

NOTE 4: Where the FP uses aggregation, the FP is not required to check whether the successive changes cancel 
one another or not. The PP should therefore be prepared to sometimes receive a notification for no real 
change. 

If indications of different types or relating to different lines are about to be sent in order to notify several events that 
occurred almost simultaneously, it is allowed to send the related indications together within a single <Event 
Notification» IE (and therefore a single {FACILITY} message). 

NOTE 5: Indications of type Line use status' and 'Handset use status' may be sent as a result of a single event; this 
is a different case which is handled in clause 7.4.1.5.2. 

7.4.1 .5.2 Events triggering 'Line and diagnostic status' list related indications 

In general any event that modifies the 'Line and diagnostic status' list shall trigger the FP to sent one or more line and 
diagnostic indications to at least those PPs that are affected by the change. Aggregation of indications of almost 
simultaneous events is allowed (as indicated above) if these indications are of the same type and (if line related) occur 
on the same line. 

In some cases and in order to reduce the number of notifications to be sent, no notification shall be sent. This includes 
following cases: 

• some intermediate states in the'OK status' field (see clause 7.4.34.3.2) shall not be notified. 

Types of notifications: With the help of the three indications types (see clause 7.4.1.5.1), it is possible to distinguish 
five different types of notifications within the Line and Diagnostic Statuses List: 

1) Line related change where the Line use status has changed 

2) Line related change where the Handset use status has changed 

3) Line related change, where both the Line use status and Handset use status have changed 

4) Line related change, but concerning other statuses than the Line use and Handset use statuses 

5) Non line related change 

Use of a common message for indications relating to the same event: Indications relating to a single event should 
use the same «Events-notification» IE (and therefore the same {FACILITY} message). 

EXAMPLE 1 : Most line use status changes will result in a simultaneous change of the 'handset use status' (case 3 
above). In that case, the resulting 'Line use status' indication and 'Handset use status' indication 
should be combined into one single {FACILITY} message. 

EXAMPLE 2: In the case of a single error implying that the 'OK status' of several lines will become 'down', the 
diagnostic indications for the various lines should be sent into one single {FACILITY} message. 

7.4.1 .5.2.1 'Line use status' indication 

The table 15a describes the event types that shall trigger a 'Line use status' indication from the FP. 
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Table 15a: Event types triggering a 'Line use status' indication 



Event 


Specified line 


Targeted PPs 


A line use status has changed 


Line whose 'Line use status' field has 
changed 


At least all PPs attached to 
the line where the change 
occurred (note) 


A PP is newly attached to a line 


Line to which the PP is newly attached 


The newly attached PP only 


NOTE: A PP shall check whether a received notification concerns a line it is attached to; otherwise 
the PP may ignore the notification. 



For a 'line use status' indication, the « Events notification » information element shall be filled with the values given 
in table 15b. 

Table 15b: Values used within {FACILITY} message for a 'Line use status' indication 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«Events notification» 








<Event type> 


5 


Line use status indication 


<Event sub type> 


All 


The 'Line use status' value 


<Event multiplicity> 


All 


The line identifier value itself 



Upon reception of a {FACILITY} message with a content as defined in table 15b, the PP shall follow the display 
requirements as given in table 41 in clause 7.4.34.2. Line use status information is indicated directly in the <Event 
subtype>. 

7.4.1 .5.2.2 'Handset use status' indication 

The following table describes the event types that shall trigger a 'Handset use status' indication from the FP. 

Table 15c: Event types triggering a 'Handset use status' indication 



Event type 


Specified line 


Targeted PPs 


A handset previously not in use 
on the specified line has just 
become in use on that line, or 
vice versa (note 1 ) 


Line whose 'Handset use status' field 
has changed 


At least all PPs attached to 
the line where the change 
occurred (note 2) 


NOTE 1 : A handset is said here to be 'in use' if it is engaged in an external call; this event type is 

therefore relating to the specified line. 
NOTE 2: A PP shall check whether a received notification concerns a line it is attached to; otherwise 

the PP may ignore the notification. 



For a 'handset use status' indication, the « Events notification » information element shall be filled with the values 
given in table 15d. 

Table 15d: Values used within {FACILITY} message for a 'Handset use status' indication 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«Events notification» 








<Event type> 


6 


Handset use status indication 


<Event sub type> 


All 


Not used 


<Event multiplicity> 


All 


The line identifier value itself 



Upon reception of a {FACILITY} message with a content as defined in table 16, the PP may follow the display 
requirements as given in table 41 in clause 7.4.34.2. This may require access to the 'Line and diagnostic status' list. 

7.4.1 .5.2.3 'Diagnostic' indication 

The following table describes the event types that shall trigger a 'Diagnostic' indication from the FP. 
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Table 15e: Event types triggering a 'Diagnostic' indication 



Event 


Related status 
change 


Specified line 


Targeted PPs 


Event 
subtype 


Call forwarding (either CFU, 
CFNA or CFB) is activated or 
deactivated on a line 


'Call forwarding 
status' 


Line whose 'call forwarding 
status' field has changed 


At least all PPs attached to 
the line where the change 
occurred, (note 1) 


'1'H (note 2) 


A line is no longer usable (down) 
or is up again (note 5) 


Line related 'OK 
status' 


Line where local or network 
error occurs or ceases to 
occur. 


At least all PPs attached to 
the line where the error 
occurred or ceased to occur. 


'1'H (note 2) 


Line-relating local or network 
diagnostic error as indicated by 
error number, is occurring or 
ceases to occur 


Line related 
'Diagnostic error 
status' 


A non line specific service 
provided by the FP is down or up 
again (see clause 7.4.34.3.2 for 
examples of services) (note 5) 


System related 
'OK status' 


None 


All PPs attached to the 
system. 


'2'H (note 3) 


Non line-relating local or network 
diagnostic error as indicated by 
error number, is occurring or 
ceases to occur 


System related 
'Diagnostic error 
status' 


None 


Location registration of the PP 
(note 4) 


Not a status 
change related 
indication 
(unconditional 
sending) 


A line the PP is attached to 
(note 4) 


The PP performing location 
registration (and only this PP) 


'1'H (note 2) 


New attachment of a PP to a line 


Not a status 
change related 
(unconditional 
sending) 


The newly attached line id 


The PP newly attached to the 
line 


'1'H (note 2) 


NOTE 1 : A PP shall check whether a received notification concerns a line it is attached to; otherwise the PP may ignore the 

notification. 
NOTE 2: "Line related change". 
NOTE 3: "Non line related change". 
NOTE 4: The notification is sent after the location registration is completed successfully. It is sent once for each line the PP 

is attached to. See also clause 7.4.34.2. 
NOTE 5: A important case is system reboot if completed after the NG DECT chipset is setup (so lines and system are up 

after the PPs performed location registration). Diagnostic indications should be aggregated as much as possible if 

several events triggering diagnostic indications (line related or not) occur during that period. 



Almost simultaneous events: Several events (i.e. status list changes) occurring almost simultaneously may be the 
subject of a single notification. 

For Diagnostic indication the « Events notification » information element shall be filled with the values given in 
table 15f. 

Table 15f: Values used within {FACILITY} message for a 'Diagnostic' indication 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«Events notification» 








<Event typo 


7 


Diagnostic indication 


<Event sub typo 


1,2 


1 : Line related changes only 
2: Non line related changes only 
(note 1) 


<Event multiplicity> 


All 


The line identifier value itself (note 2) 


NOTE 1 : For changes in the 'Line use status' the Line use status indication is used instead and for changes in the 

'Handset use status' the Handset use status indication is used instead. 
NOTE 2: If the <Event subtype> is '2', the <Event multiplicity> field holds a don't care value. 



Upon reception of a {FACILITY} message with a content as defined in table 15f, the PP shall follow the display 
requirements as given in table 505 in clause 7.4.34.2. This may require access to the 'Line and diagnostic status' list. 
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7.4.1.6 



SMS Message notification 



Upon reception of a short message from the network for a given SMS service, the FP shall send to all PPs accessing this 
SMS service (i.e. to all PPs attached to the line used by the SMS service), an SMS message notification using the 
generic events notification. The notification shall only be sent when the whole message has been received. 

The new incoming short message shall be indicated by the FP to the PPs through a Generic events notification with 
event type 'SMS message' (see EN 300 175-5 [5], clause 7.7.55) and with one of the following event subtypes: 

A new SMS message just arrived (value OIH). 

No new SMS message arrived, but some other list change(s) triggered the notification (value 02H). 

SMS service identification: The SMS message notification shall always be sent with an SMS service identifier, sent in 
a «C ALL-INFORM ATION» IE within the same {FACILITY} message, and using subtype 'SMS service identifier'. 

Simultaneous 'list change indication': A 'list change indication' for the 'Incoming SMS List' shall be sent together 
with the 'SMS message notification', in the same «Events notification» IE. 

Conversely, a 'list change indication' for the 'Incoming SMS List' shall never be sent alone, but always within an 'SMS 
message notification'. 

The <event multiplicity> field of the 'list change indication' shall contain the total number of entries in the 'Incoming 
SMS List' /or the specified SMS service, at the time the notification is sent ('unread' plus 'read' SMS messages). 

«Events notification» information element shall be filled with the values specified in table 15g. 

Table 15g: Values used within {FACILITY} message for SMS message notification 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«List change details» 






Optional (sent only if PP supports 
extended notification, and if full 
resync not requested by FP) 


<Originating PP> 



All other 


Not a single PP, or FP originating 
Originating PP terminal id number 


<List of added or modified 
entry ids> 


All 




<List of deleted entry lds> 


All 




«Events notification» 








<Event type> 


5 


SMS message 


<Event sub type> 


1 
2 


A new SMS message just arrived 
(see note 1). 

No new SMS message arrived, but 
some other list change(s) triggered 
the notification (see note 2) 


<Event multiplicity > 


0..127 


Number of unread messages, for the 
specified SMS service 


<Event type> 


3 


List change indication 


<Event sub type> 


11 


Incoming SMS List 


<Event multiplicity > 


All 


Total number of elements in the list 
for the specified SMS service 


«Call lnformation» 








<ldentifier type> 


3 


Service identifier 


<ldentifier sub type> 





SMS service identifier 


<ldentifier value> 


All 


The SMS service identifier value 
itself 


NOTE 1 : Value 01 H is used for notifying the PR (and end user) of a change (or set of changes close in time) in the 
Incoming SMS List (and concerning the indicated SMS service). The change or set of changes notified 
includes one single SMS arrival for that SMS service. Conversely, only a single notification with this 
subtype value can be used for any given SMS. 

NOTE 2: Value 02H is used for notifying a change (or set of changes close in time) in the Incoming SMS List that 
do not include any new SMS arrival. 
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Upon reception of a { FACILITY } message with a content as defined in table 15g, the PP shall indicate the SMS status 
to the receiving user. 

SMS deactivation notification: As a particular case, as soon as the number of unread messages for a given line is '0', 
the FP shall send a 'SMS message notification' to all PPs attached to the line used by the SMS service, with the <Event 
multiplicity> field (for the 'SMS message' part of the notification) set to '0'. 

NOTE: This notification allows the PP to give a hint to the user that the Incoming SMS List does no longer need 
to be consulted for the specified SMS service (e.g. by switching off a LED). 

SMS message waiting notification after successful location registration: An SMS message notification shall be sent 
by the FP after successful location registration of the PP, once for each SMS service the PP has access to (i.e. if attached 
to the line used by that SMS service). One {FACILITY} message per SMS service accessible from the PP shall be used. 

7.4.2 Date and Time synchronization 

All mandatory requirements as defined in clause 7.4.2 of TS 102 527-3 [18] shall apply. 

7.4.3 Handling of parallel calls 

7.4.3.1 Parallel call common requirements 

All mandatory requirements as defined in clause 7.4.3.1 of TS 102 527-3 [18] shall apply. 

7.4.3.2 Control messages 

The procedure relates to DECT systems allowing to handle several simultaneous calls, and offers a common handling of 
them in various situations (PSTN double calls, VoIP multiple calls on a single line, as well as parallel call situations 
occurring in a multiple line DECT system). 

The following control codes shall be transmitted as keypad information in (CC-INFOj (or (CC-SETUPj if explicitly 
noted) messages and shall trigger the corresponding actions in the FP according to table 17. 
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«Text changed from TS 102 527-3 [18] (modification): 



Table 17: Control messages for control of parallel calls 



Procedure 


Control message 


Direction 


PP Status 


FP status 


Outgoing parallel call initiation (Internal) 


17H + number 

1 7H + '*' (see note 1) 


PP to FP 


M 


M 


Outgoing parallel call initiation (external) 


1 CI 5H -H number (see note 2) 


PP to FP 


M 


M 


Call waiting indication (external or internal) 


Call status "CS call setup" -i- 
lE «SIGNAL = 'call waiting 
tone' = 07H» -i- IE «CLIP» 
(see notes 3 and 8) 


FP to PP 


M 


M 


Intrusion call request indication (only 
internal) 


Call status "CS conference 
connect" + IE «SIGNAL = 
'Intercept tone ON' = 02H» 
(see note 8) 


FP to PP 


M 


M 


Call toggle request (external or internal) 


1CH31H 


PP to FP 


M 


M 


3-party conference call request (external 
or internal) 


1CH32H 


PP to FP 


M 


M 


Call release (of the indicated call) 


1CH33H 


PP to FP 


M 


M 


Call transfer request (external or internal) 


1CH34H 


PP to FP 


M 


M 


Call waiting acceptance 


1CH35H 


PP to FP 


M 


M 


Call waiting rejection 


1CH36H 


PP to FP 


M 


M 


Active call release with replacement (from 
PP to FP) 


1CH38H 


PP to FP 





M 


Negative acknowledgement 


Confirmed call status -i- IE 
«SIGNAL, 09H = negative 
acknowledgement tone» 
(see note 8) 


FP to PP 


M 


M 


Explicit call intrusion 


1CH40H in {CC-SETUP} -1- 
targeted terminal identifier 
number (handset intrusion) or 
targeted line id (line intrusion) 


PP to FP 


CI 704 


M 


Putting a call on-hold 


1CH41H 


PP to FP 





M 


Resuming a call put on-hold (see note 9) 


1CH42H 


PP to FP 


M 


M 


Call interception request from HPP (or PP) 
(see note 7) 


1CH50H in {CC-SETUP} 


PP to FP 


C1701 


M 


Outgoing parallel DTAM call initiation 


1CH20H-i-DTAMid 


PP to FP 


M 


M 


Call screening acceptance 


1CH48H 


PP to FP 


M 


M 


Call screening interception 


1CH49H 


PP to FP 


M 


M 


C1 701 : If the PT is a headset PP THEN "M" ELSE "0". 

CI 704: "0" if implicit call intrusion procedure is supported, "M" if implicit call intrusion not supported. Note that this is 

because at least one of the intrusion call procedures (implicit/explicit) shall be supported (see status of 

procedures of NG1.N10 in table 9). 


NOTE 1 : The '*' is used to call all the registered handsets (except the initiator) and the FP when capable of; this function 

is also called "internal general call" as defined in Generic Access Profile (GAP) EN 300 444 [11]. It may be 

also used when only two PPs are registered (this allow to omit the terminal number). 
NOTE 2: This value is purposely distinct from '1 5'H value, although it is used here in a similar context. Use of 31 H, 32H, 

33H, 35H, etc., as number after 15H may have a specific meaning for the network. For backward compatibility 

reasons, the FP may have to interpret these codes as control messages or send them transparently to the 

network. 
NOTE 3: Numbering plan id field of CLIP IE is set to "private numbering plan" for internal calls, any other type for 

external calls (as specified in TS 102 527-1 [17]). 
NOTE 4: The definition of the new CO-control code 1 C is proposed for use as described in table 1 7. 
NOTE 5: The new DECT codes may need a translation into network control messages on FP side. These messages 

are network operator dependent. 
NOTE 6: Network control messages may be sent directly by the user as keypad information. The FP should send them 

transparently to the network. 
NOTE 7: "Call interception" means that a PP intercepts a call initiated (i.e. being setup or in active state) by another PP. 

The intercepting PP is in principle a headset PP but could be any standard PP (see clause 7.4.16.2). This 

control code will be transmitted as keypad information in a {CC-SETUP} message. 
NOTE 8: See clause 7.4.6.4 for the definition of call statuses. Presence of «Signal» IE depends on the "Tones 

provision" feature. See clause 7.4.3.4 for more details on the negative acknowledgement. 
NOTE 9: "Resuming a call put on hold" (1 C 42H) is mandatory for PPs since it may be needed by the call release 

procedure (see clause 7.4.3.5.4). The control code may be sent after interaction with the user, or automatically 

by the PP. 



End of change» 
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7.4.3.3 Codec change for parallel calls 

All mandatory requirements as defined in clause 7.4.3.3 of TS 102 527-3 [18] shall apply. 

7.4.3.4 Sending negative acknowledgement 

All mandatory requirements as defined in clause 7.4.3.4 of TS 102 527-3 [18] shall apply. 

7.4.3.5 Common parallel call procedures (external or internal) 

All mandatory requirements as defined in clause 7.4.3.5 of TS 102 527-3 [18] shall apply. 

7.4.3.6 Call transfer 

All mandatory requirements as defined in clause 7.4.3.6 of TS 102 527-3 [18] shall apply. 

7.4.3.7 3-party conference with established external and/or internal calls 

All mandatory requirements as defined in clause 7.4.3.7 of TS 102 527-3 [18] shall apply. 

7.4.3.8 Intrusion call (from PP to FP) 

All mandatory requirements as defined in clause 7.4.3.8 of TS 102 527-3 [18] shall apply. 

7.4.3.9 Internal call codec priority 

All mandatory requirements as defined in clause 7.4.3.9 of TS 102 527-3 [18] shall apply. 

7.4.3.10 Handling of lines where second calls are signalled in-band 

All mandatory requirements as defined in clause 7.4.3.10 of TS 102 527-3 [18] shall apply. 

7.4.4 Handling of single call services 

All mandatory requirements as defined in clause 7.4.4 of TS 102 527-3 [18] shall apply. 

7.4.5 Line identification 

All mandatory requirements as defined in clause 7.4.5 of TS 102 527-3 [18] shall apply. 

7.4.6 Call identification 

7.4.6.1 Call identification general requirements 

All mandatory requirements as defined in clause 7.4.6.1 of TS 102 527-3 [18] shall apply. 

7.4.6.2 Call identifier assignment on first outgoing call (FP to PP) 

All mandatory requirements as defined in clause 7.4.6.2 of TS 102 527-3 [18] shall apply. 

7.4.6.3 Call identifier assignment on first incoming call (FP to PP) 

All mandatory requirements as defined in clause 7.4.6.3 of TS 102 527-3 [18] shall apply. 
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7.4.6.4 Call status indication to the handset (FP to PP) 

7.4.6.4.1 Call status indication general requirements 

All mandatory requirements as defined in clause 7.4.6.4.1 of TS 102 527-3 [18] shall apply. 

7.4.6.4.2 Call status indication as call information 

All mandatory requirements as defined in clause 7.4.6.4.2 of TS 102 527-3 [18] shall apply. 

7.4.6.4.3 Call status principles and values 
General rules. The following three call statuses shall always be sent: 

• 'CS call setup' (for all incoming calls); 

• 'CS idle' (for all calls, incoming or outgoing, first or parallel). However, the use of the 'CS idle' call status for 
the last released call is optional (see clause 7.4.3.5.4); and 

• 'CS call connect' (for all incoming and outgoing calls, first or parallel, but only when the call is end to end 
connected from PP to remote system, and unless 'CS conference connect' is used). 

NOTE 1: Contrary to the 'CS call connect', the {CC-CONNECT} message indicates local U-plane connection and 
is sometimes sent before the call is end to end connected. 

The rules for using call statuses are further detailed in the "Values summary and condition of use' clause below and 
especially in table 30. 

Other call statuses shall also be sent by the FP if applicable or upon reception of the corresponding information from the 
network. 

A {CC-INFOj message shall not be used to convey a call status for the first call before the { CC-CONNECT }has been 
sent. In this case, the standard CC message shall be used instead. 

Contrary to the case of first calls, the procedure "Call status indication to the handset" introduces the concept of a state 
machine on PP side for the handling of parallel calls. Consequently, call statuses for a parallel call are not conveyed 
within specific CC messages and shall always be sent using the all-purpose {CC-INFOj message type. 

Call statuses for a first outgoing call. Call statuses shall be used for a first outgoing call. The sending of a call status 
by the FP shall be as timely and accurate as possible with regard to the external world situation (network, other 
handsets). 

For a 'Non early {CC-CONNECT}' implementation of the FP, the sending of a call status for a first outgoing call shall 
coincide with the sending of the corresponding CC message: 

• the call statuses 'CS call setup ack', 'CS call proc', and 'CS call alerting' are optional and shall be sent in 
{CC-SETUP-ACK}, {CC-CALL PROC), {CC-ALERTING}respectively. The call status is used if and only if 
the corresponding message is used; 

• the call status 'CS call connect' shall always be used (if the call succeeds), and shall always be sent in the 
{CC-CONNECT} message. 

For an 'Early {CC-CONNECT}' implementation the sending of a call status for a first outgoing call shall be done by 
means of a {CC-INFO} message for call statuses sent after the {CC-CONNECT}. More specifically: 

• the {CC-CONNECT} message shall not bear any call status; 

• the call statuses 'CS call setup ack', 'CS call proc', and 'CS call alerting' are optional and-for those which are 
used-shall be sent in this order in separate {CC-INFO {messages following the {CC-CONNECT} message; 

• the call status 'CS call connect' shall always be used (if the call succeeds) and shall be sent after the previously 
mentioned call statuses in a {CC-INFO} message following the {CC-CONNECT} message. 
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Call statuses for a parallel outgoing call. Call statuses shall be used for a parallel outgoing call. More specifically: 

• the call statuses 'CS call setup ack', 'CS call proc', and 'CS call alerting' are optional and - for those which are 
used-shall be sent in this order in separate {CC-INFO} messages, as part of the outgoing parallel call initiation 
(see clause 7.4.3.5.1); 

• the call status 'CS call connect' shall always be used (if the call succeeds) and shall be sent after the previously 
mentioned call statuses in a {CC-INFO} message. 

Call statuses for a first incoming call. Call statuses shall be used for a first incoming call. More specifically: 

• the call status 'CS call setup' shall always be used, and shall be sent within the incoming { CC-SETUP } 
message; 

• the call status 'CS call connect' shall always be used, and shall be sent within a {CC-INFO} following the 
{CC-CONNECT-ACK} message. The {CC-CONNECT-ACK} message shall never be used to convey any 
call status. 

Call statuses for a parallel incoming call. Call statuses shall be used for a parallel incoming call. More specifically: 

• the call status 'CS call setup' shall always be used, and shall be sent in a {CC-INFO} message, as part of the 
call waiting indication (see clause 7.4.3.5.2); 

• the call status 'CS call connect' shall always be used, and shall be sent in a {CC-INFO {message if (and after) 
the call is accepted (see clause 7.4.3.5.6). 

NOTE 2: The sending of the 'CS call connect' call status by the FP for a first incoming call corresponds to the 

sending of the {CC-CONNECT-ACK} message, but is however sent in a separate {CC-INFO} message. 

Call statuses for held and released calls. Call statuses shall be used for putting a call on-hold or for releasing a call: 

• the call status 'CS call hold' shall be used, and shall be sent in a {CC-INFO} message, in order to put a call 
on-hold (see clauses 7.4.3.5.1 and 7.4.3.5.8); 

• the call status 'CS idle' shall be used, and shall be sent in a {CC-INFO}message, if the call is to be released on 
PP side (see clause 7.4.3.5.4). However, use of this call status is optional for the last call; 

• as soon as a call is held (CS call hold) or released (CS idle) and until another call is connected (CS call 
connect), the FP shall play appropriate audio toward the PP. Appropriate audio consists in: 

audio received from the network if any (e.g. announcements); 

audio translation of network events if any (e.g. waiting call message from network); 

mute patterns otherwise (FP sends mute pattern as defined in TS 102 527-1 [17]). 

NOTE 3: If an additional local muting is performed on PP side during those "transition" periods, this should be 
carefully handled as this would also mute possible audio received from the network or FP (e.g. inband 
call waiting tones, network announcements). 

Call remote status notification. 'CS call remote connect' and 'CS call remote hold' call statuses are used to notify the 
PP of the connected or on-hold status of the call on remote handset side. See table 30 below and clause 7.4.3.5.12 (call 
remote status notification) for more details. 

«Text changed from TS 102 527-3 [18] (addition): 

Call status for the first call screened: The following procedure applies: 

• The 'CS call setup' call status is always used, sent within the incoming {CC-SETUP} message. 

• The 'CS call connect' call status is always used, sent within {CC-INFO} following the {CC-CONNECT-ACK} 
message. The {CC-CONNECT-ACK} message shall never be used to convey any call status. 

• The 'CS screening setup' call status is always used, sent within the incoming {CC-INFO} message. 
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• The 'CS screening connect' call status is always used, sent within {CC-INFO} following the {CC-CONNECT} 

message. 

End of change» 

Special case of PSTN calls. The use of call statuses for external calls on a PSTN line is described in procedure 
'Handling of lines where second calls are signalled in-band' of clause 7.4.3.10. 

Values summary and condition of use. Table 30 explains use of the call status values defined in EN 300 175-5 [5], 
clause 7.7.56, "Call information". 

«Text changed from TS 102 527-3 [18] (modification, CS screening setup and CS screening connect rows added 
to table): 

Table 30: Call status value explanation 



Call status 


Use 


Status 


Explanation 


CS call setup 


Incoming 
call 


IVlandatory for incoming calls 


Incoming call presentation to local handset 
The handset has not yet confirmed user alerting 
(e.g. CS call alerting not yet sent) 


CS call setup ack 


Outgoing 
call 


If and only if the FP (or the 
network) is expecting to collect 
further dial information 




CS call proc 


Outgoing 
call 


If and only if the network 
provides corresponding 
signalling 


Call is proceeding. Dial information is assumed to be 
complete. The FP has started outgoing call towards 
the network (or internal party). No final response from 
network or internal party has been received yet 


CS call alerting 


Outgoing 
call 


If and only if the network 
provides corresponding 
signalling or for internal call 


Outgoing call is signalled (ring back) at called party 
side. A waiting call uses a control code for the same 
purpose in the opposite direction 


CS call connect 


Both 


IVlandatory for all successful 
calls (unless CS conference 
connect is used) 


End to end call is connected from PP to remote 
system, and locally active; voice is available if the 
remote handset is also connected (i.e. not on hold) 


CS call 
disconnecting 


Both 




Disconnect in progress, used from FP to differ the 
sending of 'CS idle' in order to signal in-band and/or 
Call status reason information to the handset 


CS call hold 


Both 


If and only if applicable 


connection is being held locally 


CS call under 
transfer 


Both 


If and only if applicable 


Used for unannounced call transfer in 

clause 7.4.3.6.2, to indicate that the incoming call is 

used for a call transfer 


CS conference 
connect 




If and only if applicable 


3PTY conference is active 

If used, replaces CS call connect 


CS call 
intercepted 




If and only if applicable 


Used in the "Headset management" feature (see 
clause 7.4.16.2.2, Call interception) 


CS idle 


Both 


Mandatory for all calls except 
the last call; Optional for the 
last call 


Indicates that the corresponding call context shall be 
deleted on PP side at least. For more detail, see 
clauses 7.4.3.5.4 and 7.4.6.1 


CS call remote 
connect 


Call remote 

status 

notification 


Optional for the PP and the FP 


Status of the call on the remote end of that call is 
'connected' or 'on-hold' respectively; see 
clause 7.4.3.5.12 (call remote status notification). 
These remote statuses allow to improve the local PP 
MMI, but do not interfere in any way with the local 
statuses defined above 


CS call remote 
hold 


Call remote 

status 

notification 


Optional for the PP and the FP 


CS screening 
setup 


Screened 
incoming 
call 


If PP and FP are screening 
capable and screening is 
activated on both sides 


Call screening indication. Indicates to a screening PP 
that call screening has started for the presented call 


CS screening 
connect 


Screened 
incoming 
call 


If screened call has been 
accepted (i.e. in screening 
mode) by the PP with 1 C48H 


End to end call connected from PP to remote system. 
Call is locally in screening mode 



«end of change» 

7.4.6.4.4 Call status reasons summary and MMI mapping 

All mandatory requirements as defined in clause 7.4.6.4.4 of TS 102 527-3 [18] shall apply. 
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7.4.6.4.5 Call statuses for a first "Outgoing external call" 

All mandatory requirements as defined in clause 7.4.6.4.5 of TS 102 527-3 [18] shall apply. 

7.4.6.4.6 Call statuses for a first "Outgoing external call" 
using early {CC-CONNECT} message 

All mandatory requirements as defined in clause 7.4.6.4.6 of TS 102 527-3 [18] shall apply. 

7.4.6.4.7 Call statuses for an "Outgoing external call" - user busy 

All mandatory requirements as defined in clause 7.4.6.4.7 of TS 102 527-3 [18] shall apply. 

7.4.6.4.8 Call statuses for an "Outgoing external call" - number not available 

All mandatory requirements as defined in clause 7.4.6.4.8 of TS 102 527-3 [18] shall apply. 

7.4.6.4.9 Call statuses for a first "Incoming external call" 

All mandatory requirements as defined in clause 7.4.6.4.9 of TS 102 527-3 [18] shall apply. 

7.4.6.4.10 Call statuses for a first "Incoming external call" 

All mandatory requirements as defined in clause 7.4.6.4.10 of TS 102 527-3 [18] shall apply. 

7.4.7 Multiple lines handling 

All mandatory requirements as defined in clause 7.4.7 of TS 102 527-3 [18] shall apply. 

7.4.8 Multiple call line handling 

All mandatory requirements as defined in clause 7.4.8 of TS 102 527-3 [18] shall apply. 

7.4.9 PP and FP capabilities indication and broadcast 
7.4.9.1 Terminal capability indication 

The following text replaces clause 7.4.9.1 of TS 102 527-3 [18] and shall apply (see tagged changes). 

Clause 8.17 of EN 300 444 [1 1] (GAP) shall be replaced by the following procedure. 

The PP shall be able to send the «Terminal capability» information element and the FP shall be able to receive it at 
least in {ACCESS-RIGHTS-REQUEST} and when location registration is supported in the {LOCATE-REQUESTj. 
The following text together with the associated clauses define the mandatory requirements with regard to the present 
document. 

«Text changed from TS 102 527-3 [18] (modification, table modified): 

Table 35: Values used within the «TERMINAL CAPABILITY» information element 



Information 
element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Terminal 
capability» 


<Display capability> 


All 


If PI supports feature (GAP.N.24) it 
shall indicate in this field value which 
is equal to or higher than 2 


<Tone capability> 


All 




Echo parameters 


3 


VoIP compatible TCLw. See note 1 


Ambient noise Rejection 
(N-REJ) 


[1,2] 


See note 2 
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Information 
element 



Field within the 
information element 



Standard values within the 
field/information element 



Normative action/comment 



Adaptive volume control 
(A-VOL) 



[1,2,3] 



See note 2 



Slot type capability 



<Profile indicator_1 >, 
bit 2 



<Profile indicator_6>, 
bite 



<Profile indicator_6>, 
bit? 



<Profile indicator_7>, 
bits 2, 3 and 7 



<Profile indicator_7>, 
bit 4 



<Profile indicator_7>, 
bits 



<Profile indicator_7>, 
bite 



DSAA2 (Octet 5) 



DSC2 (Octet 5) 



<Control codes> 



All 



Full and long 640 slots mandatory; 
double and long 672 optional. See 
also note 2 



"xxxxx1x"B 



GAP and/or PAP supported 



"xXxxxxx"B 
X-[0.11 



Fast or slow hopping radio 



"Xxxxxxx"B 
X = [0, 1] 



Support (or not support) of 
"no-emission" mode (optional IVIAC 
service [NG1.IVI. 5]) 



"1xxx11x"B 



New Generation DECT part 1 
(wideband speech), part 3, (extended 
wideband speech services) and part 5 
(additional feature set nr.1 for 
extended wideband voice services) 
supported 



"xxxXxxx"B 
X = [0, 1] 



Support (or not support) of the 
"Headset management" feature 
[NG1.N.21] 



"xx1 xxxx"B 



Support of the 'Re-keying' and 'default 
cipher key mechanism early 
encryption' (related to feature 
[GAP.N.35]) 



"xXxxxxx"B 
X = [0, 1] 



Support (or not support) of the 
'associated melody' per contact 
(related to procedure 'PT Alerting 
using pattern signaling' 7.4.1 .9) 



[0,1] 



Support (or not support) of the DSAA2 
(see EN 300 175-7 [7]) 



[0,1] 



Support (or not support) of the DSG2 
(see EN 300 175-7 [7]) 



All 



If PT supports feature (GAP.N.25) it 
shall indicate in this field value which 
is equal to or higher than 2 



NOTE 1 : PPs compliant with the present document shall always set the value 3 ('1 1 'B) as result of the audio type 
requirements (see clause 6.8 table 7). FPs shall also understand the values 1 ('01 'B) and 2 ('10'B) that 
may be set by PPs compliant with NG-DECT Part 1 [17] or GAP [11] when attached to FPs compliant to 
the present document. 

NOTE 2: This capability is assumed as the default value (see table) if the «TERIVIINAL-CAPABILITY» 
information element is omitted. 



End of change» 
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The capabilities in table 36 shall be assumed as default if the following fields in the «TERMINAL CAPABILITY» 
information element are not present. 

«Text changed from TS 102 527-3 [18] (modification, row for bit 5(re-keying) and note 3 added): 

Table 36: Values assumed as terminal capabilities 



Information element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Terminal capability» 


<Echo parameters> 


3 


VoIP compatible TCLw (see 
note 1 ) 


<N-REJ> 


1 


No noise rejection 


<A-VOL> 


1 


No PP adaptive volume control 


<Slot type capability> 


"xxx1x1x"B 


Full slot and Long slot (j=640) 
supported (see note 2) 


<Profile indicator 6>, 
bit 7 


"Oxxxxxx"B 


No support of "no-emission" mode 
(optional IVIAC service [NG1.M.5]) 


<Profile indicator 6>, 
bit 4 


"xxxOxxx"B 


No support of the "Headset 
management" feature [NG1.N.21] 


<Profile indicator 7>, 
bits 


"xxl xxxx"B 


Support of "Re-keying" and 
"default cipher key early encryption 
mechanism" (see note 3) 


DSAA2 (Octet 5) 





No support of the DSAA2 


DSC2 (Octet 5) 





No support of the DSC2 


NOTE 1 : Value 3 (VoIP compatible TCLw) shall be assumed if the PP has declared to be a NG-DECT Part 5 or 

Part 3 PP. For GAP and NG-DECT Part 1 PPs the default values given in [11] and [17] shall be assumed. 

NOTE 2: This value shall be assumed if the PP has declared to be a NG-DECT Part 5, Part 3 or Part 1 PP. For GAP 
PPs the default values given in [1 1] shall be assumed. 

NOTE 3: This value shall be assumed if the PP has been declared to be a NG-DECT Part 5 PP. 



End of change» 

No echoing of characters is allowed in the FT and therefore the PT would be responsible for displaying dialled digits. 
All display information from the FT would be assumed to be additional information that the PT shall display in 
addition. The PT shall logically separate display information originating at the FT and PT. This could be achieved, for 
example, by one physical display and two logical displays or two physical displays and two logical displays. The key 
point is that display characters from the PT and FT shall not be simultaneously interleaved/mixed on the same physical 
display. 

7.4.9.2 Higher layer information FP broadcast 

All mandatory requirements as defined in clause 7.4.9.2 of TS 102 527-3 [18] until start of clause 7.4.9.2.1 shall apply. 

7.4.9.2.1 Higher layer information in standard FP broadcast (Qh = 3) 

All mandatory requirements as defined in clause 7.4.9.2.1 of TS 102 527-3 [18] shall apply. 

7.4.9.2.2 Higher layer information in Extended FP broadcast (Qh = 4) 

All mandatory requirements as defined in clause 7.4.9.2.2 of TS 102 527-3 [18] shall apply. 

7.4.9.2.3 Extended Higher Layer capabilities part 2 (Qh = 11) 

The following text replaces clause 7.4.9.2.3 of TS 102 527-3 [18] and shall apply (see tagged changes). 

The Extended Higher Layer capabilities, part 2, Fixed Part Information field shall be used indicating the supported set 
of Wideband speech Services. 
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«Text changed from TS 102 527-3 [18] (modification): 

Table 37: Extended Higher Layer Capabilities part 2 interpretation by the PP 



BIT Number 


Attribute 


Value 


Note 


<a24> 


NG-DECT Wideband voice 
supported 


1 


See TS 102 527-1 [17] (see notes 1 and 2) 


<a29> 


NG-DECT extended 
wideband voice services 
supported 


1 


See TS 102 527-3 [18] (see notes 1 and 2) 


<a30> 


Permanent CLIR 


1 


Related procedures: clause 7.4.12 


031 > 


Three-party conference call 
(external or external) 


1 


Related procedures: clause 7.4.3.7 


<a32> 


Intrusion call 


1 


Related procedures: clause 7.4.3.8 


<a33> 


Call deflection 


[0,1] 


Related procedures: clause 7.4.4.1 .1 , 7.4.4.2 


<a34> 


Multiple lines 


[0,1] 


Related procedures: clause 7.4.7 


<a35> 


"no emission" mode support 


[0,1] 


Related procedures: see NG1.IVI.5 in clause 6.12 


<a36> 


NG-DECT Part 5 (additional 
feature set nr.1 for extended 
wideband voice services) 
supported 


1 


The present document (see notes 1 and 2) 


<a42> 


Support of 'Re-keying' and 
'early encryption' 


1 


Support of the 'Re-keying' and 'default cipher key 
mechanism early encryption' procedures (related 
to feature [GAP.N.35]) 


<a43> 


DSAA2 supported 


[0,1] 


Support (or not support) of the DSAA2 See 
EN 300 175-7 [7]. 


<a44> 


DSC2 supported 


[0,1] 


Support (or not support) of the DSC2 See 
EN 300 175-7 [7] and note 3. 


NOTE 1 : Value refers to the value to be set by FPs complying with the present document. PPs may need to 
understand other values due to the compatibility with GAP and NG-DECT Part 1 FPs. 

NOTE 2: All equipment compliant with the present documents shall broadcast and shall understand the "Extended 
Higher layer capabilities (part 2)". 

NOTE 3: The support of the DECT Standard Cipher #2 (DSC2) requires the support of the DECT Standard 
Authentication Algorithm #2 (DSAA2). 



Even if a capability bit relates to a feature which is mandatory in the present document, this bit shall be set (indicating 
the support of the feature). Setting only the bit a^(^ NG-DECT " Part 5 "additional feature set nr.l for extended 
wideband voice services supported" is not enough. 

End of change» 

7.4.10 List access service 
7.4.10.1 General considerations 

All mandatory requirements as defined in clause 7.4.10.1 of TS 102 527-3 [18] until subsection 'Entry identifier' shall 
apply. 

Entry identifier: 

All mandatory requirements as defined in clause 7.4. 10. l/'Entry identifier' of TS 102 527-3 [18] shall apply. 

Field identifier: 

All mandatory requirements as defined in clause 7.4.10.1/'Field identifier' of TS 102 527-3 [18] shall apply. 

Field instances management: 

The following text replaces clause 7.4.10.1/'Field instances management' of TS 102 527-3 [18] and shall apply (see 
tagged changes). 
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Most of the time, the FP supports only one instance of a given field in a given list. However, for some fields in some 
lists, the FP supports several instances of the same field (same field id) in a given entry. The concerned fields and 
corresponding lists are the following: 

• Field 'Contact number' in the Contact List (see clause 7.4.10.5.1.11). The FP shall support at least two 'Contact 
number' field instances for all entries in the Contact List (i.e. the maximum number of instances supported 
shall be greater or equal to 2). Different contacts may have different numbers of 'Contact number' field 
instances. See clause 7.4.10.5.7. 

• Field 'Blocked number' in the Line Settings List (see clause 7.4. 1 1 .4.7). The FP may implement several 
'Blocked number' field instances in every entry of the Line Settings List. 

• Field 'FP IP address / DNS server' in the DECT System Settings List (see clause 7.4.11.3. 8). 

The PP may use the 'Query supported entry fields' command (see clause 7.4.10.4.2) in order to be informed of the 
maximum number of instances supported by the FP for a field. 

Available instances. Instances held by the FP in a given entry are called available instances. There may be less 
instances available in a given entry than supported by the FP. Different entries may hold different number of instances 
for the same field. 

However, there shall be at least one available instance for each implemented field {navailable - !)■ If there are no data 
currently associated with the field, this instance shall be empty. Empty field (instances) are defined in clause 7.4.10.5.1. 

NOTE 1 : This empty instance needs not be actually stored by the FP, but has to be present over the air. Apart from 
this specific case, available instances are always non-empty (see clause 7.4.10.4.5.1, "Save entry" 
command). 

NOTE 2: When the FP supports a maximum of one instance for a field, this single instance is therefore always 
available. 

EXAMPLE 1 : An instance shall always be available for the following single-instance fields, although there may 
be no defined value for them at a given point in time (empty instance used): 

'Number' field in call lists, when the number is not known. 

'Dialling prefix', when no dialling prefix has been defined by the user. 

Ordering of instances. The FP shall respect the order of instances received from the PP at all times: at entry creation 
and at entry modification (and especially in the case of instance deletion). This order of instances shall be respected 
over the air when the entry is requested again by one of the PPs. 

NOTE 3: The PP may re-order instances when displaying them on its MMI. This re-ordering does not imply any 

re-ordering of the instances on FP side, unless the PP specifically requires this through a subsequent save 
command. 

NOTE 4: In order to delete an existing instance, the PP uses the 'Save entry' command. See clause 7.4.10.4.5. 

Requesting entries. When requesting entries (i.e. when using 'Read entries', 'Search entries', or 'Edit entry'), the PP 
specifies the number of instances requested inreauested) ^'^^ ^ given field by repeating the corresponding field id as 
many times. The PP may request any number of instances for a field inreauested ^ t^' "^D- ^^^ ^ shall ignore the 
field id occurrences exceeding the number of instances it supports. 

EXAMPLE 2: A PP could always request as many instances of the field as it is able to handle on its MMI. This 
number may exceed the maximum number of instances supported by the FP for the field. 

The FP shall answer in the command confirmation with available instances, in the order they are stored on FP side. If 
there are less instances available on FP side than requested by the PP {nayaHajjig < nyeauested^' '■^^ ^^ ^^^^^ answer 
with all instances available; Otherwise (i.e. if n^yailable ^ '^requested')' *e FP shall answer with the first n^g^Mg^fej 
instances. 

NOTE 5: If n^gce/vec/ is ^e number of received instances, n^gce/vec/ = '^^("available^ f^requested^ 
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Saving existing entry. When saving an existing entry, the PP shall send at least all nreceived instances received during 
the previous edit entry confirm answer (with possible modifications or deletions). ^^ nreceived ^ ^reauested' '■^^ ^^ ™^y 
save more instances than received (thus adding extra instances). However, the total number of saved instance shall 
never exceed the number of requested instances. 

NOTE 6: This can be summarized as: n^^^eived ^ ^^saved ^ ^^requested. 

NOTE 7: This only applies if the PP saves the field. Otherwise, n^^^^^ = 0. In other words, if no modification is 

done by the PP on any instances of a field, all instances of the field should be simply omitted by the PP in 
the save. 

«Text changed from TS 102 527-3 [18] (modification): 

A non-editable field or field instance shall never appear in the 'save entry command'. Otherwise, a 'Procedure not 
allowed' negative acknowledgement shall be used by the FP. See clause 7.4.10.4.5. 

End of change» 

Saving new entry. When creating a new entry, the PP may send any number of instances. The FP shall discard instances 
exceeding the maximum number of instances it supports. 

NOTE 8: However, the PP should use the 'Query supported entry fields' command (see clause 7.4. 10.4.2) in order 
to avoid handling and sending more instances than supported by the FP for the field. 

List index: 

All mandatory requirements as defined in clause 7.4.10.1/'List index' of TS 102 527-3 [18] shall apply. 

Bytes order: 

All mandatory requirements as defined in clause 7.4.10.1/'Bytes order' of TS 102 527-3 [18] shall apply. 

Guarantee of service: 

All mandatory requirements as defined in clause 7.4.10.1/'Guarantee of service' of TS 102 527-3 [18] shall apply. 

Display and edition of string fields: 

All mandatory requirements as defined in clause 7.4.10.1/'Display and edition of string fields' of TS 102 527-3 [18] 
shall apply. 

Alphabet compatibiUty: 

All mandatory requirements as defined in clause 7.4. 10.1/' Alphabet compatibility' of TS 102 527-3 [18] shall apply. 

Initial values: 

All mandatory requirements as defined in clause 7.4.10.1/'Initial values' of TS 102 527-3 [18] shall apply. 

Guarantee of interactivity for the user: 

All mandatory requirements as defined in clause 7.4.10.1/'Guarantee of interactivity for the user' of TS 102 527-3 [18] 
shall apply. 

7.4.1 0.2 List change notification 
7.4.10.2.1 General rule 

The following text replaces clause 7.4.10.2.1 of TS 102 527-3 [18] and shall apply (see tagged changes). 
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The present 'List change notification' procedure describes the use of the 'list change indication' type of generic events 
notification (see clause 7.7.55 of EN 300 175-5 [5]). It is potentially usable with any of the lists described in 
clause 7.4.10.5, but: 

• Clause 7.4.10.2.2 enumerates the lists for which the present procedure makes a 'list change indication' 
mandatory. Use of the procedure for other lists is optional and may not be relevant. 

• The 'Missed Calls List' does not use the list change notification procedure (see clause 7.4.10.2) for the sending 
of list change indications. The procedure 7.4.1.3 'Missed call notification' describes all uses of a 'list change 
indication' for the 'Missed Calls List'. 

«Text changed from TS 102 527-3 [18] (addition): 

• The 'Line and diagnostic statuses' list does not use the list change notification procedure (clause 7.4.10.2). 
Clause 7.4.1.5 'Line and diagnostic statuses notifications' describes all uses of an 'events notification' for the 
'Line and diagnostic statuses' list. 

• The 'Incoming SMS' list does not use the list change notification procedure (clause 7.4.10.2). Clause 7.4.1.6 
'SMS message waiting notification' describes all uses of an 'events notification' for the 'Incoming SMS' list. 

End of change» 

Line identification used in a 'list change indication': As a general rule: 

• If the list contains a line identifier field, a 'line change indication' shall contain a line identifier, specified in a 
«CALL INFORMATION» IE. The line id to be used is described below (see 'Events triggering the 
notification' clause). 

• If the list does not contain any line identifier, the list change indication shall NOT contain any 
«CALL-INFORMATION» IE. 

Event multiplicity: The <event multiplicity> field shall contain the total number of entries in the list/or the specified 
line id at the time the notification is sent. More specifically: 

• If the specified line id subtype 'Line identifier for external call' or 'Relating to' is used, the entries with 'All 
lines' value shall not be counted. 

• If the specified line id subtype is 'All lines', only entries with this subtype shall be counted. 

NOTE 1 : As a result, if one entry of the Line Settings List is modified, a list change notification is sent with the 
event multiplicity value set to 1, together with a «CALL INFORMATION» IE set to 'Relating to' 
subtype and the line identifier value (see also clause 7.4.10.2.2). 

Events triggering the notification: When the present 'List change notification' procedure is implemented by the FP for 
a list, the following event types shall trigger a 'list change indication' from the FP. For each event type, the line to 
specify and the set of PPs receiving the notification (targeted PP or PPs) are indicated. 

• Entry created, modified, or deleted. If an entry in the list is created, modified or deleted, a 'list change 
indication' shall be sent. 

Specified line (only if the list contains a line identifier field): The line id subtype used, and the value used 
(if any value) shall be those of the concerned entry. 

NOTE 2: If the line id subtype 'All lines' is used, the line id value field is absent. 

Targeted PPs: All PPs attached to the specified line: 

■ If the concerned entry relates to a single line (line id subtype 'Line identifier for external call' or 
'Relating to'), the notification shall be sent to all PPs attached to the corresponding line. 

■ If the concerned entry contains a line identifier field with 'All lines' subtype, the notification shall 
be sent to all registered PPs (and shall contain the 'All lines' line id subtype, as already stated 
above). 

NOTE 3: The Contact List may use both types of targeted PPs, depending on the concerned entry. 
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■ If the list does not containing any line identifier field, the targeted PPs shall depend on the list and 
on the context (see clause 7.4.10.2.2). 

• Base reset: If the FP is reset, a 'list change indication' shall be sent once for each line. 

NOTE 4: If a list is lost (i.e. erased from memory) as a result of the base reset, a 'list change indication' is sent with 
<Event multiplicity> field set to '0'. 

Specified line: Line for which the notification is sent (once for each line). 

Targeted PPs: All PPs attached to the specified line. 

NOTE 5: The purpose of this notification is re-synchronise the PPs with the lists state, when the lists have changed 
during the base reset. 

• Location registration: A 'list change indication' shall be sent after location registration, once for each line the 
PP is attached to (1 FACILITY message per line the PP is attached to). 

Specified line: Line for which the notification is sent (once for each line the PP is attached to). 

Targeted PP: The PP performing location registration (and only this PP). 

NOTE 6: A location registration request ({LOCATE-REQUEST} message) is sent by the PP when the handset is 
switched on. A location registration request could be sent by the PP when it goes back in range (after it 
got out of range) in order to inform the FP that it may have lost some notifications. 

Almost simultaneous events: Several events (i.e. list changes) occurring almost simultaneously may be the subject of a 
single notification, provided the following rules are respected: 

1) all events notified together shall occur on, or concern, the same list; 

2) all events notified together shall occur on, or concern, the same line (same line id subtype and value). 

Notifications shall be sent by the FP by use of the "generic event notification" procedure. For indication of list change 
and values used in «Events notification» information element, consider table 39. 

Table 39: Values used within {FACILITY} message for list change indication 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«Events notification» 


<Event typo 


3 


List change indication 


<Event sub typo 


All 


List identifier as indicated in 
clause 7.4.1 0.3 


<Event multiplicity > 


0..127 


Total number of entries in the list 
(see note 1) 


«Call lnformation» 






See note 2 


<ldentifier type> 





Line identifier 


<ldentifier sub typo 


'Line identifier for 

external call', 'Relating 

to', or 'All lines' 


The 'None' value is excluded 


<ldentifier valuo 


All 


The line identifier value itself if 

present 

(absent if 'All lines' subtype is used) 


NOTE 1 : 'Event multiplicity' can be extended for values up to 16 383 by using the following extension mechanism: If 
the bit at bit position 8 of the first octet is set to then a second octet will follow, if this bit is set to 1 then 
no further octet will follow. For values greater than 127 the first octet contains the 7 most significant bits 
and the bit at bit position 8 is set to whereas the second octet contains the 7 least significant bits and 
the bit at bit position 8 is set to 1 . For values below 128 the first octet contains the 'Event multiplicity' value 
and the bit at bit position 8 is set to 1 indicating that no second octet will follow. Examples: decimal value 
1 28 is coded as 01 H 80H, decimal value 1 7 is coded as 91 H and decimal value 1 is coded as 81 H. 

NOTE 2: «Call information» only present if list change indication is related to one or more lines. 
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7.4.10.2.2 Mandatory notifications 

The following text replaces clause 7.4.10.2.2 of TS 102 527-3 [18] and shall apply (see tagged changes). 

«Text changed from TS 102 527-3 [18] (modification): 

In order to allow the display of information in idle mode on PP side, notifications shall be sent by the FP for the 
following lists (but only if the list is implemented): 

End of change» 

• Line Settings List (defined in clause 7.4.11.4). As indicated in clause 7.4.10.2.1, changes in an entry of this list 
shall be notified to all PPs attached to the line identified by the field 'Line id' of that entry. However for fields 
which are optional or which do not require the PP to update its user interface, notification is optional or 
irrelevant (see clause 7.4. 11. 4). 

NOTE 1 : This allows in particular the PP to immediately update the line name in other lists entries (e.g. if used 
instead of the line id when the list is presented to the user). 

• Internal Names List. A change in this list shall be notified when a PP modifies the name of another PP (if the 
FP allows it), and the list change notification shall at least be sent to that other PP concerned by the change. 
Furthermore the FP shall send a list change notification to all PPs when a PP has been added to this list (e.g. as 
a result of a registration) or removed from this list (e.g. as a result of a de-registration). 

«Text changed from TS 102 527-3 [18] (addition): 

• Contact List 

NOTE la: Thanks to this notification, a PP maintaining a local copy of the common Contact List (caching) may be 
aware of changes made in the Contact List and retrieve these changes as soon as possible. 

• 'All Calls List' (also in the case of a missed call, although the Missed Calls List itself is not handled in 
clause 7.4.10.2) defined in clause 7.4.10.5.6 of [20]. As indicated in clause 7.4.10.2.1 [21], changes in this list 
shall be notified to all PPs attached to the line identified by the field 'Line id' of the modified entry (or entries): 

If the call type is 'missed call', the notification shall be sent each time a 'missed call notification' is sent, 
and in addition to it (see clause 7.4.1.3). 

If the call type is 'outgoing call' or 'incoming call', this notification shall be sent in addition to the list 
change notification for the 'Outgoing Calls List' or 'incoming call list' respectively. 

• Outgoing Calls List 

• Incoming call list 

NOTE lb: Thanks to call list notifications, the PP is able to give access to the user to up to date call lists 
immediately after a call was added to them. 

EXAMPLE: Where a PP uses the list change notifications to retrieve the call lists most recent entries through 
batch processing, the PP is able to present an up to date 'Missed Calls List' to the user shortly after 
(s)he missed a call, and the user is therefore able to re-dial the number immediately. 

• Sent SMS List 

• Outgoing SMS List 

• Draft SMS List 

NOTE Ic: Thanks to SMS related notifications, a PP maintaining a local copy of SMS list (caching) may be aware 
of changes made (by the PP user or from other PPs) immediately after an SMS was added to them. 

End of change» 

For all other lists, sending of notifications is left free to the implementor. However, the possibly important extra 
processing on FP and PP sides necessary for sending and handling notifications (e.g. if sent for each call) shall be 
carefully taken into account. 
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«Text changed from TS 102 527-3 [18] (modification): 

NOTE 2: The present 'List change notification' procedure cannot be used for the Missed Calls List and the Line and 
Diagnostic Statuses List, as stated in clause 7.4.10.2.1. 

End of change» 

7.4.1 0.3 List identifier codings 

The following list identifier codings are defined: 

«Text changed from TS 102 527-3 [18] (modification, nine lists inserted before 'Reserved'): 

Bits 87654321 Meaning 

00000000 List of Supported Lists 

1 Missed Calls List 

10 Outgoing Calls List 

1 1 Incoming Accepted Calls List 

10 All Calls List 

10 1 Contact List 

110 Internal Names List 

111 DECT System Settings List 

10 Line Settings List 

10 1 All Incoming Calls List 

00001010 Line and Diagnostic Statuses List 

10 11 SMS Settings List 

110 Incoming SMS List 

110 1 Sent SMS List 

1110 Outgoing SMS List 

1111 Draft SMS List 

10 DTAM Settings List 

10 1 DTAM Incoming Calls List 

10 10 DTAM Welcome Message List 

1 xxxxxxx Reserved for proprietary lists 
all other values reserved 

End of change» 

The lists shall be sorted on the FP, using default criteria for each of them. The default sorting criteria are the following: 
«Text changed from TS 102 527-3 [18] (modification): 

• The "Missed calls", "Outgoing calls", "Incoming accepted call" lists, "All Incoming Calls List" and more 
generally all call-related lists shall be sorted by default using the "Date and time" field. This also includes the 
DTAM Incoming Calls List if the DTAM feature is implemented. 

End of change» 

«Text changed from TS 102 527-3 [18] (addition): 

• The DTAM welcome messages list shall be sorted by default using the 'DTAM full identifier', and then using 
the 'message position index' (criterion 2). 

• All SMS lists (except for the SMS Settings List) shall be sorted by default using the "Date and Time" field as 
well. 

End of change» 

• The "Contact" list shall be sorted by default using the "Name" field (first criterion). If the names are equal the 
list should be sorted using the "First name" field (criterion 2). 

• The Internal Names List shall be sorted by default using the "Number" field (terminal id number). 
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«Text changed from TS 102 527-3 [18] (modification): 

• The Line Settings List, SMS Settings List, and DTAM Settings List shall be sorted by default using the "Line 
id" field. 

End of change» 

• The DECT System Settings List and List of Supported Lists are not sorted by default as they contain only one 
entry. 

«Text changed from TS 102 527-3 [18] (addition): 

• The Line and Diagnostic Statuses List shall be sorted by default using the "Line id" field. 

End of change» 

Please refer to the "Start session" command for a definition of the sorting order used for a given field type (this 
definition applies independently of the position of the field in the sorting process: i.e. whether used as "first criterion", 
"criterion 2", etc.). 



7.4.10.4 



List Access Commands 



The following text replaces clause 7.4.10.4 of TS 102 527-3 [18] and shall apply (see tagged changes). 

The following list access commands are defined: 

«Text changed from TS 102 527-3 [18] (modification, 'read selected entries' and 'write entry' commands are 
added): 

Bits 



87654321 


Meaning 


PP -> FP 


FP -> PP 


00000000 


start session 


yes 


- 


00000001 


start session confirm 


- 


yes 


00000010 


end session 


yes 


yes 


0000001 1 


end session confirm 


yes 


yes 


00000100 


query supported entry fields 


yes 


- 


00000101 


query supported entry fields confirm - 


yes 


000001 10 


read entries 


yes 


- 


000001 1 1 


read entries confirm 


- 


yes 


00001000 


edit entry 


yes 


- 


00001001 


edit entry confirm 


- 


yes 


00001010 


save entry 


yes 


- 


0000 1011 


save entry confirm 


- 


yes 


00001 100 


delete entry 


yes 


- 


0000 1101 


delete entry confirm 


- 


yes 


0000 1110 


delete list 


yes 


- 


0000 1111 


delete list confirm 


- 


yes 


00010000 


search entries 


yes 


- 


00010001 


search entries confirm 


- 


yes 


00010010 


negative acknowledgement 


- 


yes 


0001 001 1 


data packet 


yes 


yes 


00010100 


data packet last 


yes 


yes 


0001 0101 


read selected entries 


yes 


- 


0001 Olio 


read selected entries confirm 


- 


yes 


000101 1 1 


write entry 


yes 


- 


0001 1000 


write entry confirm 


- 


yes 


1 xxxxxxx 


reserved for proprietary list access 


commands 




all other values reserved 







End of change» 

Proprietary list access commands shall have list access command codings with most significant bit set to '1'. 

The "read entries", "read entries confirm" and "search entries confirm" commands use a start index as these command 
may apply to a range of entries within a list. 
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The "save entry confirm" command uses a position index as this command applies to one entry. 

Possible error codes are specified for each command from PP to FP. They use negative acknowledgement command, 
with exception of negative start session confirm. 

Additionally to the general status of a given command and a given list as described in table 9 for feature [NG1.N.16], 
the PP shall follow the following more detailed requirements: 

«Text changed from TS 102 527-3 [18] (modification, 'read selected entries' and 'write entry' commands, nine 
new lists at the end and three notes are added to the table): 

Table 40: PP commands support status per list 



List (with status as given 

in table 9, feature 

[NG1.N.16]) 


Command (with status as given in table 9, feature [NG1.N.16]) 




Start/end 

session 

(M) 


Query 
supported 

entry 
fields (0) 


Read 

entries 

(M) 


Read 

selected 

entries 

(0) 


Edit 
entries 

(M) 


Save 

entry 

(M) 


Write 

entry 

(M) 


Delete 

entry 

(M) 


Delete 
list (M) 


Search 

entries 

(M) 


Lists of supported lists (0) 


M 


1 


M 





1 


1 


1 


1 


1 


1 


Missed Calls List (M) 


M 





M 





1 
(note1) 


1 
(note 1) 


1 


M 


M 





Outgoing Calls List (0) 


M 





M 





1 


1 


1 


M 


M 





Incoming Accepted Calls 
List (M) 


M 





M 





1 


1 


1 


M 


M 





All Calls List (0) 


M 





M 





1 


1 


1 


M 


M 





Contact List (M) 


M 





M 





M 


M 





M 





M 


Internal Names List (IVI) 


M 





M 





M 


M 





M 


1 





All Incoming Calls List (0) 


M 





M 





1 

(notes 1 

&2) 


1 

(notes 1 

&2) 


1 


M 


M 





DECT System Settings List 
(M) 


M 





M 





M 


M 





1 


1 


1 


Line Settings List (IVI) 


M 





M 





M 


M 








1 


1 


Line and Diagnostic 
Statuses List (M) 


M 





M 





1 


1 


1 


1 


1 





Incoming SIVIS List 
(C1303) 


M 





M 





1 
(note 1) 


1 

(notel) 


1 


M 


M 





Sent SMS List (C1 303) 


M 





M 





1 


1 


1 


M 


M 





Outgoing SMS List 
(C1303) 


M 





M 





M 


M 





M 


M 





Draft SMS List (CI 304) 


M 





M 





M 


M 





M 


M 





SMS Settings List (C1 303) 


M 





M 





M 


M 








1 


1 


DTAM Settings List 
(C1305) 


M 





M 





M 


M 








1 


1 


DTAM Incoming Calls List 
(C1306) 


M 





M 





1 


1 


1 


M 
(note 3) 


M 
(note 3) 





DTAM Welcome Message 
List (C1 305) 


M 





M 





1 


1 


1 


M 
(note 3) 


M 
(note 3) 





C1303: IF NG1.N.24 (SMS) THEN "M" ELSE "1". 

C1304: IF NG1.N.24 (SMS) THEN "0" ELSE 'T'. 

C1305: IF NG1.N.25 (DTAM) THEN "M" ELSE "1". 

C1306: IF NG1.N.25 (DTAM) and Visual DTAM implemented THEN "M" ELSE IF NG1.N.25 THEN "0" ELSE "1". 

NOTE 1 : The command may however be used for editing the 'Read status' field (and only that field). The 'Read status' field is 

the only editable field in this list (see Annex H). Other fields of the list may however be present in the edit entry. 
NOTE 2: For the All Incoming Calls List, the Read status field is only used (and is only editable) for missed calls. 
NOTE 3: The command may however fail for a remote voice oriented DTAM. 



End of change» 

EXAMPLE: If the PP implements the 'list of supported list' (optional list), PP shall then implement 'start 

session', 'end session' and 'read entries' commands, other commands for this list are irrelevant. 

Additionally to the general status of a given command and a given list as described in table 9 for feature [NG1.N.16], 
the FP shall follow the following more details requirements. 
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«Text changed from TS 102 527-3 [18] (modification, 'read selected entries' and 'write entry' commands and 
nine new lists at the end are added to the table; notes 5, 6 and 7 are added): 

Table 41 : FP commands support status per list 



List (with status as given 

in table 9, feature 

[NG1.N.16]) 


Command (with status as given in table 9, feature [NG1.N.16]) 




Start/end 

session 

(M) 


Query 
supported 

entry 
fields (M) 


Read 

entries 

(M) 


Read 

selected 

entries 

(M) 


Edit 
entries 

(M) 


Save 
entry (M) 


Write 
entry (M) 


Delete 

entry 

(M) 


Delete 
list (M) 


Search 
entries 

(M) 


Lists of supported lists (M) 


M 


1 (note 1 ) 


M 




(note 2) 


1 
(notel) 


1 (note 1 ) 


1 (note 1 ) 


1 
(notel) 


1 
(note 1) 


1 
(notel) 


IVIissed Calls List (M) 


M 


M 


M 




(note 2) 


1 
(note 6) 


1 (note 6) 


1 (note 1 ) 


M 


M 


M 


Outgoing Calls List (0) 


M 


M 


M 




(note 2) 


1 
(notel) 


1 (note 1 ) 


1 (note 1 ) 


M 


M 


M 


Incoming Accepted Calls 
List (M) 


M 


M 


M 




(note 2) 


1 
(notel) 


1 (note 1 ) 


1 (note 1 ) 


M 


M 


M 


All Calls List (M) (note 5) 


M 


M 


M 




(note 2) 


1 
(note 1) 


1 (note 1 ) 


1 (note 1 ) 


M 


M 


M 


Contact List (M) 


M 


M 


M 




(note 2) 


M 


M 




(note 2) 


M 


M 


M 


Internal Names List (M) 


M 


M 


M 




(note 2) 


M 
(note 4) 


M 
(note 4) 




(note 2) 


M 
(note 4) 


1 
(note 1) 


M 


All Incoming Calls List (0) 


M 


M 


M 




(note 2) 


1 (note 
6&7) 


1 (note 
6&7) 


1 (note 1 ) 


M 


M 




(note 2) 


DECT System Settings List 

(M) 


M 


M 


M 




(note 2) 


M 
(note 4) 


M 
(note 4) 




(note 2) 


1 
(notel) 


1 
(notel) 


1 
(notel) 


Line Settings List (M) 


M 


M 


M 




(note 2) 


M 
(note 4) 


M 

(notes 3 

and 4) 




(note 2) 




(notes 2 
and 4) 


1 
(note 1) 


1 
(notel) 


Line and Diagnostic 
Statuses List (M) 


M 


M 


M 


1 
(note 1) 


1 
(notel) 


1 (note 1 ) 


1 (note 1 ) 


1 
(notel) 


1 
(note 1) 


M 


Incoming SIVIS List (C1 303) 


M 


M 


M 


M 


1 
(note 6) 


1 (note 6) 


1 (note 1 ) 


M 


M 


M 


Sent SMS List (C1 303) 


M 


M 


M 


M 


1 
(note 1) 


1 (note 1 ) 


1 (note 1 ) 


M 


M 


M 


Outgoing SIVIS List (C1 303) 


M 


M 


M 


M 


M 


M 


M 


M 


M 


M 


Draft SMS List (C1 303) 


M 


M 


M 


M 


M 


M 


M 


M 


M 


M 


SMS Settings List (C1 303) 


M 


M 


M 




(note 2) 


M 


M 




(note 2) 



(note 2) 


1 
(note 1) 


1 
(note 1) 


DTAM Settings List 
(C1304) 


M 


M 


M 




(note 2) 


M 
(note 4) 


M 
(note 4) 



(note 2) 




(notes 2 
and 4) 


1 
(note 1) 


1 
(notel) 


DTAM Incoming Calls List 
(C1305) 


M 


M 


M 




(note 2) 


1 
(note 1) 


1 (note 1 ) 


1 (note 1 ) 


M 
(note 8) 


M 
(note 8) 


M 


DTAM Welcome Message 
List (C1 304) 


M 


M 


M 




(note 2) 


1 
(notel) 


1 (note 1 ) 


1 (note 1 ) 


M 
(note 8) 


M 
(note 8) 


M 


C1303: IF NG1.N.24 (SMS) THEN "M" ELSE "1". 

C1304: IF NG1.N.25 (DTAM) THEN "M" ELSE "1". 

C1 305: IF NG1 .N.25 (DTAM) and Visual DTAM implemented THEN "M" ELSE IF NG1 .N.25 THEN "0" ELSE "1". 


NOTE 1 : FP shall answer with negative acknowledgement / 'procedure not allowed'. 

NOTE 2: If not supported, FP shall answer with negative acknowledgement / 'procedure not allowed'. 

NOTE 3: FP shall support the command to offer the possibility to modify a line setting. However, the 'save entry' for creating a 

new line need not be supported by the FP. See clause 7.4.10.4.5.2. 
NOTE 4: Additional requirements apply when a PP is involved in a voice call. FP shall temporarily restrict access to the list during 

the duration of the voice call. See clause 7.4.10.6 for details. 
NOTE 5: Additional requirement as a delta to NG-DECT Part 3 [3]: the 'all calls' list related commands support is mandatory. 
NOTE 6: FP shall answer with negative acknowledgement / 'procedure not allowed' unless the command is used to edit the 'Read 

status' field only. The 'Read status' field is the only editable field in this list (see Annex H). Other fields of the list may 

however be present in the edit entry. 
NOTE 7: For the All Incoming Calls List, the Read status field is only used (and is only editable) for missed calls. 
NOTE 8: The command need not be supported for a remote voice oriented DTAM. 



End of change» 
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7.4. 10.4.1 Start and end session 

All mandatory requirements as defined in clause 7.4.10.4.1 of TS 102 527-3 [18] shall apply. 

7.4. 10.4.2 Query supported entry fields 

All mandatory requirements as defined in clause 7.4.10.4.2 of TS 102 527-3 [18] shall apply. 

7.4.10.4.3 Read entries 

All mandatory requirements as defined in clause 7.4.10.4.3 of TS 102 527-3 [18] shall apply. 

7.4.10.4.4 Edit entry 

All mandatory requirements as defined in clause 7.4.10.4.4 of TS 102 527-3 [18] shall apply. 

7.4.10.4.5 Save entry 

7.4.1 0.4.5.1 "Save entry" command 

The following text replaces clause 7.4.10.4.5.1 of TS 102 527-3 [18] and shall apply (see tagged changes). 

This command from PP requests to save the entry in the list identified by the specified entry identifier, or to add a new 
entry to the list. Corresponding entry is sent along in data packets. 

The list entries which are saved shall have been requested via 'edit' before in the same session, except for creation of a 
new entry. 

Saving of an existing entry: 

The 'save' transaction shall contain all fields or a subset of the fields which were submitted in the 'edit' transaction. 
Other fields (not edited, or edited but not saved) remain unchanged in the FP. 

«Text changed from TS 102 527-3 [18] (addition): 

Non-editable fields shall not be present in the save command. This applies to manufacturer-defined and standard 
defined non-editable fields (see Annex H). 

End of change» 

For more information, see clause 7.4.10.1, 'Field instances management' entry. 
Best effort mode: 

When receiving the data packets following the 'save entry' command, the FP shall work in best effort mode: 
Saving the new value (or instance values) proposed for all fields for which it is possible. 



• 



• Not saving the new value (or instance values) proposed for a field if it is not possible, i.e. in the following 
error cases: 

'PIN code required' error case for a PIN protected field without prior correct PIN reception in the current 
call; or 

'content not accepted' error case for a malformed field; or 

'procedure not allowed' error case for a non-editable field. 
«Text changed from TS 102 527-3 [18] (deletion, note deleted): 
End of change» 

• Sending a negative acknowledgement ('PIN code required', 'content not accepted', 'procedure not allowed') at 
the end of the command if applicable, even if the command was partially carried out. 
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NOTE 1 : The steps described above for field (instance) modification apply also for: 

■ field resetting of an editable single instance PIN protected field (this is a kind of field 
modification); 

■ field instance deletion or addition of a multiple instance PIN protected field. 

NOTE 2: This means that when an error is encountered, all subsequent fields in the command will still be processed 
by the FP even if the sending of a negative acknowledgement is planned for the command. 

• If several error codes apply, the FP shall send one of them. 

NOTE 3: Owing to the previous requirements, the FP might send a 'PIN code required' negative acknowledgement 
even when an unchanged PIN protected field is included in the 'save entry' command (i.e. if the correct 
PIN was not received before). The PP may avoid this drawback by saving only modified PIN protected 
fields or e.g. by systematically asking the user for the PIN in the session if the list contains PIN protected 
fields). 

NOTE 4: The "best effort" mode aims at handling several error situations. However in most cases, the FP will 
successfully save all fields included in the 'save entry' command. 

Table 52: Values used within {IWU to IWU} information element for "Save entry" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 


<Protocol Discriminator> 


03H 


List access 


<Command = save entry> 


AH 


List access command 


<Session identifier> 


1..127 


Session identifier (see note) 


<Entry identifier> 


0..127 


Entry identifier (see note) 


NOTE: Session identifier' and 'entry identifier' can be extended for values up to 1 6 383 by using the same 
meclianism as for 'Event multiplicity'. See note 1 at table 39. 



Content of list entry is transmitted in data packets. 
Entry identifier: 



Bits 7 6 5 4 3 21 

0000000 
other values 

New entry creation: 



Meaning 

not yet assigned entry identifier (new entry proposed by the PP) 
assigned entry identifier (this entry identifier shall already exist in the list) 



If a new entry has to be created, the PP shall indicate this by using the entry identifier OOH. In this case, the end FP shall 
assign a new entry identifier for the entry and submit it in the following 'save entry confirm'. 

For more information, see clause 7.4.10.1, 'Field instances management' entry. 

The FP entry identifier assignment method is left free to implementation. However, the FP should not re-assign a 
previously freed (e.g. because of deletion of an entry) entry identifier before all sessions which were accessing this list 
at the time of freeing the entry identifier have been closed. By this way, possible inconsistencies in other PPs which 
have active sessions to the same list are avoided. 

The FP may implement the " re-use if possible method " described below. 

The "re-use if possible method" consists in assigning an entry identifier to a new entry in the interval [1, n] for a given 
list: 

• Assignment starts or restarts at 1 when list is empty. 

• For further entries, if only 1 session is opened on the list, the rule "Assigned id = smallest free id" applies. Free 
id may correspond to a never used or previously freed entry id. 
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• For further entries, if more than one session is opened on the Hst, the rule "Assigned id = smallest free id" 
applies, with the additional requirement that the assigned id shall have remained free (i.e. shall not have been 
used and then deleted) since the list was in idle the last time. 

• This method assumes that n is never reached, n is larger than maximum number of entries in the list. 
New or modified entry insertion in the list: 

The new or modified entry shall be inserted in the list by the FP taking into account the sorting criteria for this list. 

Edit command without modification: 

If the previously started edit procedure has to be terminated without changing the list entry, PP shall perform the 'save 
entry' procedure with only one empty 'last data packet' following the 'save entry' (an example is provided in 
clause C.5.9). 

Field instance reset, emptying or deletion with a save entry command: 

A PP may request the reset, emptying or deletion of a field instance by using an empty field instance in a "save entry" 
command (length of the field instance set to 1). Table 53a lists the different cases. 

Field reset allows to reset the field in the FP and come back to its default value (defined in the present document or 
manufacturer defined). When resetting a field instance, the FP shall replace it in the list entry with the (non-empty) 
default value defined for that field. 

NOTE 5: It has to be noted that for some fields in some lists, resetting can be dangerous and should be carefully 
controlled by the PP. 

Field emptying allows to set an empty value for the field. Applies only to a limited number of fields in the present 
document. 

Field deletion allows to delete one instance of a multiple instance field in the FP. When deleting a field instance, 
the FP shall respect the order of the remaining instances (as stated in clause 7.4.10.1, "Field instances 
management"). The deleted instance is removed from the list entry, not replaced with the received empty instance. 

NOTE 6: Empty field instances are defined in clause 7.4.10.5.1. 

«Text changed from TS 102 527-3 [18] (modification, SMS relating fields are added): 

Table 52a: FP behaviour when "length=1" in a save entry 



Field name 
(notel) 


FP behaviour 


Comment 


Fields which may be reset individually by the PP 


Contact List: 
- Line id 


FP shall reset the field to the 
default value (if editable) 


The FP uses the FP defined default value for a contact. 
For example, it could be the "All lines" value. 
See also note 2. 


Internal Names List: 

- Name (of handset) 

- Call interception 


FP shall reset the field to the 
default value (if editable) 


The FP uses the FP defined default value. 
See also note 2 


DECT System Settings 
List: 

- Clock master 

- Base reset 

- Emission mode 

- New PIN code 


FP shall reset the field to the 
default value (if editable) 


The FP uses the FP defined default value. 

For "base reset", default value is "YES" by standard; this 

is therefore equivalent to setting the value to "YES" 

directly (with all consequences defined in 

clause 7.4.1 1.3.3) 

See also note 2 


Line Settings List: 

- Line name 

- Attached handsets 

- FP volume 

- Multiple calls mode 

- Intrusion call 

- Permanent CLIR 

- Call forwarding (CPU, 
CFNA and CFB) 


FP shall reset the field to the 
default value (if editable) 


The FP uses the FP defined default value. 

For 'SMS validity period', default value is 24 hour by 
standard; this is therefore equivalent to setting this value 
directly (see 7.4.1 1.4.19). 

See also note 2 
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Field name 
(notel) 



FP behaviour 



Comment 



Fields which may be reset individually by the PP 



SMS Settings List: 

- Enable SMS 

- Max SMS size 

- SMS delivery report 

- SMS validity period 



Fields which may be emptied by the PP 



Name 



First name 



Dialling prefix 



FP IP address / value 



FP IP address / subnet 
mask 



FP IP address / gateway 



Associated melody 



FP melody 



SMSC Send Server 



SMSC Receive Server 



FP shall set the field to empty 
value (length=1) 



Empty value is selected because it is an allowed value for 
the field. Deletion is not applicable to those single 
instance fields. 

See also note 3. 



Fields which are always empty 



Read status 



FP IP address /type 



FP shall update the property 
octet with received bits sent by 
the PP (if field is editable) 



Save entry command can only be used with length=1 on 

those fields. 

Deletion is not applicable to those single instance fields. 



Fields which may be deleted by the PP (multiple-instance fields) 



Contact number 



Blocked number 



FP IP address / DNS 
server 



FP shall remove field instance (if 
editable) 

However, if all field instances of 
a given field are present in the 
save entry command, and have 
length=1 , all but one instances 
shall be removed in the FP; for 
the remaining one, the empty 
value shall be used (note 4) 



The PP may delete all but one instances. 

See clause7.4.10.1, "Field instance management" 

details 



for more 



NOTE 1 : Fields that are always uneditable (see Annex H) are not listed here. Such fields shall never appear in a 'save 
entry' command. Always uneditable fields include: Call type. Date and time, FP version (all subfields). Line 
name (in a call list). Line id. Number, Number of calls. This also includes the "Current PIN code" which is not 
modifiable (for this field, the FP answers "incorrect PIN"). 

NOTE 2: For those fields, an empty value is not allowed in the list entry (as stated in the field definition). As a result, 
"length = 1 " can be used in the save entry command for the purpose of resetting the field. 

NOTE 3: Individual field resetting using length=1 is NOT possible here because use of an empty-value field (i.e. with 
length = 1) in the list entry is allowed. In addition, the PP cannot reset the field directly as it happens that no 
reset value for this field is defined in the present document. Although not possible for the field individually, a 
reset value defined by the FP can still be restored through a global reset (base reset). 

NOTE 4: This implies that the PP requested all available instances of the field in the previous edit entry command. 



End of change» 

Possible error cases: 

NOTE 7: When several error cases apply (e.g. for different fields) a negative acknowledgement will be sent; 
however, the used 'reject reason' may be different from the one indicated below. 

NOTE 8: As described in clause 7.4.10.4.9, the negative acknowledgement is sent after the 'data packet last' 
information is received from the PP. 

Invalid session number: If session identifier is wrong the FP shall answer with negative acknowledgement reject 
reason 'invalid session number'. 

Entry not available: If an unknown entry identifier of the list is requested (except 0), the FP shall answer with negative 
acknowledgement, reject reason 'entry not available'. 
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Entry format incorrect: If a PP attempts to save an entry with an incorrect format, the FP shall reject the command with 
a negative acknowledgement, with reject reason "Entry format incorrect". 

Content not accepted: If a PP attempts to save an entry with correct format but with a field content which cannot be 
accepted, (e.g. for a field whose contents are only allowed once in the list like line-id in the Line Settings List or when 
too many instances of a field are saved in the same entry), the FP shall reject the command with a negative 
acknowledgement, with reject reason "content not accepted". 

List full: If a PP attempts to add a new entry in a list which cannot accept an additional entry, the FP shall reject the 
command with a negative acknowledgement, with reject reason "list full". 

PIN code required: If a PP attempts to perform an operation subject to prior correct PIN entry (e.g. PIN protected field 
modification, etc. See clause 7.4. II. 1, entry 'PIN code' for details), the FP shall send a negative acknowledgement, with 
reject reason 'PIN code required'. 

NOTE 9: As described at the beginning of the present clause and in clause 7.4.10.4.9, error codes 'content not 

accepted' and 'PIN code required' can be sent even if the 'save entry' command was partially carried out. 

Procedure not allowed: The FP shall reject the save entry command with a negative acknowledgement with reject 
reason 'procedure not allowed' in the following cases: 

• the PP inserts a non-editable field (whether actually modified or not); 
«Text changed from TS 102 527-3 [18] (modification): 

• the PP attempts to save an unlocked entry. In other words, the 'save entry' command was issued without a 
previous 'edit entry' locking the entry (or was issued after a another 'save entry' already unlocking that entry). 

End of change» 

The FP may reject the save entry command with a negative acknowledgement with reject reason 'procedure not allowed' 
in the following cases: 

• the FP does not allow the saving of new entries for a given list (e.g. for call lists, for the Line Settings List). 

NOTE 10: For lists that allow creation of a new entry initiated by the PP, it is supposed that all fields are editable on 
FP side. 

7.4.1 0.4.5.2 "Save entry confirm" command 

All mandatory requirements as defined in clause 7.4.10.4.5.2 of TS 102 527-3 [18] shall apply. 

7.4.10.4.6 Delete entry 

All mandatory requirements as defined in clause 7.4.10.4.6 of TS 102 527-3 [18] shall apply. 

7.4.10.4.7 Delete list 

AH mandatory requirements as defined in clause 7.4.10.4.7 of TS 102 527-3 [18] shall apply. 

7.4.10.4.8 Search entries 

All mandatory requirements as defined in clause 7.4.10.4.8 of TS 102 527-3 [18] shall apply. 

7.4. 10.4.9 Negative Acknowledgement 

This command from the FP rejects the previous command with a reject reason, and is sent instead of the regular 
command confirmation. 

«Text changed from TS 102 527-3 [18] (modification, 'write entry' command added): 

The FP shall wait until the erroneous command is completely received from the PP before replying with a negative 
acknowledgement. For commands containing data (i.e. for the save and write commands), this implies waiting until the 
'data packet last' information is received. 
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End of change» 

For the 'save entry' command, a negative acknowledgement with reject reason 'content not accepted' or 'PIN code 
required' may only mean partial rejection of the command. See clause 7.4.10.5.1 for more information. 

7.4. 10.4.10 Data packet / Data packet last 

7.4. 10.4.11 Read selected entries 

7.4.1 0.4.1 1 .1 "Read selected entries" command 

This command from PP requests to read a series of (not necessarily consecutive) entries in the list, or only a subset of 
the fields of these entries. This command is similar to 'Read entries', but uses a selection type and a selection description 
as input instead of a start index and counter. 

Table 63a: Values used within {IWU to IWU} IE for " Read selected entries" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 




<Protocol Discriminator> 


03H 


List access 




<Command =Read selected 
entries> 


15H 


List access command 




<Session identifier> 


1..127 


Session identifier (see note) 




<Mark entries request> 


OOH, 7FH, FFH 


Flag for requesting resetting (or 
setting) of the 'Read status' field for 
all read entries 




<Number of entry field identifiers> 


0..255 


Number of requested fields 




<List entry field identifier 1> 


0..255 


Requested field 












<List entry field identifier n> 


0..255 


Requested field 




Selection type 


1..127 


Type of selection (see note) 




Selection description 




The selection description depends 
on the selection type 


NOTE: 'Session identifier' and 'entry identifier' can be extended using the most significant bit up to 1 6 383. If more 
than one byte is used for the value, the highbyte shall be send before the lowbyte (e.g. '1' is coded as 
0x81 , '128' is coded as 0x01 0x80). 



Mark entries request (octet): 

See clause 7.4.10.4.3 ('Read entries'). 
List entry field identifier: 

See clause 7.4.10.4.3 ('Read entries'). Note however the additional 'Number of entry field identifiers' here. 

Selection type: 

The selection type describes the type of entry selection that the FP shall make in order to build the 'Read selected entries 
confirm' command. 

Bits 7 6 5 4 3 21 Meaning 

1 selection from entry id with range 

10 selection from entry identifiers 
Other values reserved 
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Selection description 

For selection type 'selection from entry identifiers'. The purpose of this selection type is to allow the PP to read a subset 
of entries in the list by submitting the corresponding series of entry ids to the FP. For this selection type the following 
table shall be used: 

Table 63b: Selection description for selection type "selection from entry identifiers" 



Selection description 
within IE 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 




<Number of requested entries> 


0..255 


Number of requested entries 




<entry identifier 1> 


1..127 


Requested entry (see note 1) 












<entry identifier n> 


1..127 


Requested entry (see note 1) 


NOTE 1 : 'Entry identifier' can be extended using the most significant bit up to 16 383. If more tlian one byte is used 
for the value, the highbyte shall be send before the lowbyte (e.g. '1' is coded as 0x81, '128' is coded as 
0x01 0x80). 

NOTE 2: (Best effort mode) When some of the requested entries are no longer available on FP side, the FP shall 
skip the unexisting entries and only provide the existing entry ids in the data packets following the 'Read 
selected entries confirm'. However, when NONE of the requested entries is available, a negative 
acknowledgement shall be sent (see 'possible error cases' below). 



For selection type 'selection from entry id with range '. The purpose of this selection type is to allow the PP to read a 
single entry in the list, and, for one of the requested entry fields, to specify a range of content bytes that will be returned 
(truncated field). 

NOTE 1 : Using this selection type, the PP is able to limit the size of the response if one of the requested fields 
would be too large. The PP may retrieve the whole field by using the command several times. 

EXAMPLE: The SMS content field of the Draft SMS List may be read by low-end PPs through several uses of 
this command. The SMS content total size is known a priori by the PP thanks to the SMS size 
field. 

Lower and upper bounds. The requested range within the content bytes is specified in the command through the lower 
bound and upper bound values. For a content of n bytes, there are (n+1) bounds, numbered 0, 1, . . ., n, such that: 

bound is the place before all content bytes, 

bounds 1 .. n-1 are the n-\ places between two consecutive content bytes, 

bound n is the place after all content bytes. 

Truncated field format. The returned truncated field format shall use the following rules: 

The truncated field shall contain the same field id value and property octet(s) values as those of the original 
(non-truncated) field. 

The truncated field content (from octet 4 on) shall contain the requested range in the original field content 
(from octet 4 on, in the original field). Range bound value shall correspond to the bound before octet 4 in the 
original field. 

The length of the truncated field (octet 2) shall contain the actual truncated field length (i.e. 
"range_upper_bound - range_lower_bound +1" if the whole requested range is available, and less than that 
otherwise). 

If the requested range is empty, the returned truncated field shall be empty (length=l). This may happen if 
both lower and upper bounds are equal, or if the lower bound is equal to the number of available bytes in the 
read field (see also note 2 in table 29). 

For this selection type, the following table shall be used. See also table 63c for examples of use. 
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Table 63c: Selection description for selection type "selection from entry id with range" 



Selection description 
within IE 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 




<Entry identifier> 


1..127 


Concerned entry identifier (see 
note 1) 




<Field identifier> 


0..255 


Concerned field id within entry 




<Byte range lower bound> 


0..127 


The range starts from the indicated 
lower bound (see note 1) 




<Byte range upper bound> 


0..127 


The range ends with the indicated 
upper bound (see notes 1 and 2) 


NOTE 1 : This field can be extended using tlie most significant bit up to 1 6 383. If more than one byte is used for the 
value, the highbyte shall be sent before the lowbyte (e.g. '1 ' is coded as 0x81 , '1 28' is coded as 0x01 
0x80). 

NOTE 2: Byte range upper bound shall be greater or equal to Byte range lower bound but should be strictly greater 
than it. Byte range upper bound may exceed the number of available bytes in the read field (in that case 
the FP automatically replaces it with this number of available bytes). The Byte range lower bound s'naW 
NOT exceed the number of available bytes in the read field. 



Table 63d: Example of returned truncated field 
with selection type "selection from entry id with range" 



Subfield | Value | Encoding 


Field 'SMS content' stored in the draft list 


SI\/1S content field id in SMS draft list 


08H 


08 


Length 


11 (decimal) 


OB 


Properties 


'1100 0000'B 


CO 


Content 




AA BB CC DD BE FF 00 1 1 22 33 


Truncated 'SMS content' field returned to PP with command 'Read selected entries' 
with range 2-8 (decimal) requested for that field 


SIVIS content field id in SMS draft list 


08H 


08 


Length 


7 (=8-2+1) 


07 


Properties 


'1100 0000'B 


CO 


Content 




CCDDEEFFOO 11 


and with range 2-12 (decimal) requested for that field 
(only available range returned, no error returned) 


SMS content field id in SMS draft list 


08H 


08 


Length 


9 (=10-2+1) 


09 


Properties 


'1100 0000'B 


CO 


Content 




CCDDEEFFOO 11 22 33 



Possible error cases: 

For all selection types. 

Invalid session number: If the session identifier is wrong the FP shall answer with negative acknowledgement reject 
reason 'invalid session number'. 

If an unknown list entry field identifier is requested, the FP shall ignore this field and continue with the next requested 
field. 

For selection type 'selection from entry identifiers'. 

Entry not available: When NONE of the requested entry identifiers are available on FP side, the FP shall answer with 
negative acknowledgement, reject reason 'entry not available'. In that case, no data packet shall follow. 

NOTE 2: In contrast to that, if at least one of the requested entries is available, the FP works in best effort mode. 
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For selection type 'selection from entry id with range'. 

Entry not available: If the requested entry identifier is not available on FP side, the FP shall answer with negative 
acknowledgement, reject reason 'entry not available'. In that case, no data packet shall follow. 

Invalid range: In the following cases: 

the Byte range lower bound is strictly greater than the number of available bytes in the read field; 

the Byte range upper bound is strictly smaller than the Byte range lower bound; 

the FP shall answer with negative acknowledgement, reject reason 'invalid range'. In that case, no data packet shall 
follow. 



7.4.10.4.11.2 



" Read selected entries confirm" command 



This command from FP confirms the "Read selected entries confirm" command with the corresponding entry/entries 
with one or several specified fields. Corresponding entry /entries are sent along in data packets in the order they were 
requested. 

NOTE: It is similar to the "Read entries' command, except that the start index is absent here. 
Table 63e: Values used within {IWU to IWU} IE for "Read selected entries confirm" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 




<Protocol Discriminator> 


03H 


List access 




<Command =read selected 
entries confirm> 


16H 


List access command 




<Session identifier> 


1..127 


Session identifier (see note) 




<Partial delivery (bit 8)> 
<Counter> (bits 1 to 7) 


0..1 
0..127 


Partial delivery owing to FP memory 

limitation 

Number of actually delivered entries 


NOTE: 'Session identifier' can be extended for values up to 16 383 by using the same mechanism as for 'Event 
multiplicity'. See note 1 at table 39. 



'Partial delivery' and 'Counter' (octet): 

See clause 7.4.10.4.3.2, "Read entries confirm" command (similar requirements). 

In the case of partial delivery, the delivered entries shall correspond to the first entries requested, in the order they were 
requested. 

7.4.10.4.12 Write entry 

7.4.1 0.4.1 2.1 "Write entry" command 

This command shall only be used between an 'edit entry' and a 'save entry' commands. 

The 'write entry' command makes it possible for the PP to write a locked entry step by step without removing the lock. 
The final save entry command shall unlock the entry. 

This command format is similar to that of 'Save entry', but uses a write type and a write description as additional input. 
However, the "Write entry' command does not remove the lock put on the entry by the preceding 'Edit entry' command. 
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Table 63f : Values used within {IWU to IWU} IE for the " Write entry" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 




<Protocol Discriminator> 


03H 


List access 




<Command =Write entry> 


17H 


List access command 




<Session identifier> 


1..127 


Session identifier (see note) 




Write type 


1..127 


Type of writing (see note) 




Write description 




The write description depends on the 
write type 


NOTE: This field can be extended using tlie most significant bit up to 16 383. When more than one byte is used 
for the value, the highbyte shall be sent before the lowbyte (e.g. '1 ' is coded as 0x81 , '1 28' is coded as 
0x01 0x80). 



Write type: 

The write type describes the kind of writing that is used by this instance of the 'write entry' command. 

Bits 7 6 5 4 3 21 Meaning 

1 write from entry id with range 

Other values reserved 



Write description 

For write type 'write from entry id with range'. The purpose of this write type is to allow the PP to write a single field in 
a single entry of the list, and, for this written entry field, to specify the range of existing bytes in the written field 
(considered before the write operation) that shall be replaced by the written bytes (i.e. a replacement field is sent 
containing the bytes to be written). 

A range is defined with lower and upper bounds, as for command 'Read selected entries' with selection type 'selection 
from entry id with range' (see 7.4. 10.4. 11). The specified range in the original written field may be of length 'zero'; in . 

The replacement field may be of length 'V (empty field). In that case the specified range is removed from the written 
entry field. 

In general, the number of written bytes (replacement field length -1) may be smaller, equal, or greater than the replaced 
range length in the original written field. 

NOTE 1 : Using this write type, the PP is able to modify one of the entry fields step by step (through several uses of 
the command), instead of modifying in one step using the 'Save entry' command only. 

Replacement field format. The replacement field format sent to the FP shall use the following rules: 

The replacement field shall contain the same field id value and property octet(s) values as those of the target 
field. 

The replacement field content (from octet 4 on) shall contain the bytes to be written in the target field content 
(starting from octet 4 on, in the targeted field). Range bound value shall correspond to the bound before 
octet 4 in the targeted field. 

The length of the replacement field (octet 2) shall contain the actual replacement field length (i.e. number of 
replacement bytes +1). 
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For this selection type, the following table shall be used: 



Table 63g: Selection description for selection type "selection from entry id with range" 



Selection description 
within IE 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 




<Entry identifier> 


1..127 


Concerned entry identifier (see 
note 1 ) 




<Field identifier> 


0..255 


Concerned field id within entry 




<Byte range lower bound> 


0..127 


The range starts from the indicated 
lower bound (see note 1) 




<Byte range upper bound> 


0..127 


The range ends with the indicated 
upper bound (see notes 1 and 2) 


NOTE 1 : This field can be extended using tlie most significant bit up to 16 383. When more than one byte is used 
for the value, the highbyte shall be sent before the lowbyte (e.g. '1 ' is coded as 0x81 , '1 28' is coded as 
0x01 0x80). 

NOTE 2: Byte range upper bound shaW be greater or equal to Byte range lower bound. Equality indicates that an 
insertion is performed (instead of a replacement). Byte range upper bound may exceed the number of 
available bytes in the original written field (in that case the FP automatically replaces it with this number of 
available bytes). 



Table 63h: Example of write operations with selection type "selection from entry id with range" 



Subfield | Value | Encoding 


Original 'SMS content' stored in the draft list 


SIVIS content field id in SMS draft list 


08H 


08H 


Length 


14 (decimal) 


OEH 


Properties 


'1100 0000'B 


COH 


Content 




'48 65 6C 6C 6F 20 47 C3 BC 6E 74 65 72'H 


Content decoded as UTF-8 string 




'Hello Gtinter' 


'SMS content' field written with range 5-5 (insertion) 


Replacement field 


08H 


08H 


Length 


1 


06H 


Properties 


'1100 0000'B 


COH 


Content 




'20 44 65 61 72'H 


New SIVIS content 




'48 65 6C 6C 6F 20 44 65 61 72 20 47 C3 

BC 6E 74 65 72'H 


New SMS content UTF-8 decoded 




'Hello DearGijnter' 


'SMS content' field written with range 1 0-1 8 (shortening) (range e.g. 1 0-1 27 also works) 


Replacement field 


08H 


08H 


Length 


1 


01H 


Properties 


'1100 0000'B 


COH 


Content 




<nothing> 


New SMS content 




'48 65 6C 6C 6F 20 44 65 61 72'H 


New SMS content UTF-8 decoded 




'Hello Dear' 


'SMS content' field written with range 1-5 (replacement) 


Replacement field 


08H 


08H 


Length 


1 


02H 


Properties 


'1100 0000'B 


COH 


Content 




69H 


New SMS content 




'48 69 20 44 65 61 72'H 


New SMS content UTF-8 decoded 




'Hi Dear' 


NOTE: This example uses an SMS content encoded in UTF-8: however, the write entry 
command works at byte level and is therefore encoding agnostic. 



Possible error cases. 

NOTE 2: As described in clause 7.4.10.4.9, the negative acknowledgement is sent after the 'data packet last' 
information is received from the PP. 

Invalid session number: If the session identifier is wrong the FP shall answer with a negative acknowledgement, with 
reject reason 'invalid session number'. 
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Entry not available: If an unknown entry identifier of the list is present in the write description, the FP shall answer 
with a negative acknowledgement, with reject reason 'entry not available'. 

Entry format incorrect: If a PP attempts to write an entry field using an incorrect field format, the FP shall reject the 
command with a negative acknowledgement, with reject reason "Entry format incorrect". 

Content not accepted: If a PP attempts to write an entry field using a correct field format but with an unacceptable field 
content, the FP shall reject the command with a negative acknowledgement, with reject reason "content not accepted". 

Invalid range: The FP shall reject the write entry command with write type 'write from entry id with range' with reject 
reason 'Invalid range' in the following case: 

• The PP uses a Byte range upper bound strictly smaller than the Byte range lower bound. 

PIN code required: If a PP attempts to perform an operation subject to prior correct PIN entry (e.g. PIN protected field 
modification, etc. See clause 7.4. 11.1, entry 'PIN code' for details), the FP shall send a negative acknowledgement, with 
reject reason 'PIN code required'. 

Procedure not allowed: The FP shall reject the write entry command with a negative acknowledgement with reject 
reason 'procedure not allowed' in the following cases: 

• the PP attempts to write a non-editable field (whether actually modified or not); 

• the PP attempts to write a field of an unlocked entry. In other words, the 'write entry' command was issued 
without a previous 'edit entry' locking the entry, or was issued after the 'save entry' unlocking the entry again. 

7.4.10.4.12.2 "Write entry confirm" command 

This command from FP confirms the write of one entry in a list and returns the position index of the written entry. 

Table 63i: Values used within {IWU to IWU} information element for "Write entry confirm" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 


<Protocoi Discriminator> 


03H 


List access 


<Command = write entry confirm> 


18H 


List access command 


<Session identifier> 


1..127 


Session identifier (see note) 


<Entry identifier> 


1..127 


Entry identifier (see note) 


<Position index> 


1..127 


Position index (see note) 


<Totai number of avaiiabie 
entries> 


0..127 


Number of avaiiabie entries in list 
after writing (see note) 


NOTE: This field can be extended using tlie most significant bit up to 16 383. When more than one byte is used 
for the vaiue, the highbyte shaii be sent before the iowbyte (e.g. '1 ' is coded as 0x81 , '1 28' is coded as 
0x01 0x80). 



The position index indicates the (possibly new) index of the entry in the list. 

The 'Total number of available entries' reflects the updated number of entries in the list after the write is performed. 

7.4.1 0.5 Lists and entry fields 

All mandatory requirements as defined in clause 7.4.10.5 of TS 102 527-3 [18] until start of clause 7.4.10.5.1 shall 
apply. 

7.4.10.5.1 Fields description 

For the fields described in the following clauses: 

Field identifier octet: 

This field value depends on the list the field is used in, and is indicated for each list in the list definition. 
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Length octet and related extension bit: 



The extension bit of the length octet of a field shall be set to 1 if the length is inferior to 128. If the length is equal or 
superior to 128, more than one byte is used for the field length, the highbyte shall be send before the lowbyte (e.g. '1' is 
coded as 81H, '128' is coded as OIH 80H). 

The length value (bits 1 to 7 if extension bit is set) shall be the set to the number of octets in the field starting 
immediately after the last length octet. In particular, it shall include the properties octet defined below. 

Empty field (instance): 

An empty field instance is defined as a field instance with no value, that is, as a field instance with a length set to '1' 
(accounting for the 'properties' octet). 

NOTE 1 : The 'value' of the field is defined here as the set of all octets of the field from octet 4 on. This should not 
be confused with the 'Value' subfield included in some field definitions. 

NOTE 2: Use of an empty field instance in a "save entry" command for field instance deletion or resetting is 
described in clause 7.4.10.4.5.1. 

Properties octet and related extension bit: 

The extension bit shall be used to extend the 'properties octet' from 1 to several octets if needed (usual DECT extension 
bit mechanism). This bit shall be set to 1 if the property bits are coded on 1 octet. 

For some fields, an "editable" property bit exists. The "editable" property bit is set to "1" by the FP to indicate to the PP 
if the field of this entry can be further modified by the PP during a save command. If so, the PP may modify the value 
(octet 4 and more) and/or the property bits (octet 3) of the field in a further save command. 

The "editable" bit itself cannot be modified by the PP (even if set to '1'). Any modification of this bit shall be 
disregarded by the FP. When creating a new entry (with a save command from PP to FP), the PP may set the "editable" 
property to any value ('0' or '1'). The FP will ignore this value and set it to the desirable value. 

NOTE 3: The "editable" bit should be set to '1' by the FP only when strictly necessary. For example call related lists 
entry fields should not be editable. Contact List entry fields should be editable. 

The "editable" property bit does not restrict the set of fields that can be requested in the 'edit' command itself, which is 
provided for editing an entry as a whole. Any field (editable or not) can be included in an 'edit entry' command. 

PP requirement: The PP should prevent edition of non-editable fields (i.e. with "editable" property reset), to avoid 
misleading the user, and shall not insert a non-editable field in the following save entry command (see 
clause 7.4.10.4.5). 

NOTE 4: For some fields, the "editable" property is liable to change over the lifetime of the FP (see "FP 
requirements" below and annex H); the PP should be carefully implemented in order to take this 
flexibility into account. 

FP requirement: Annex H summarises for each field, if it shall be editable, if it shall not be editable, or if the editable 
field value is left free to the implementer. In the latter case: 

• the "editable" field value may vary with time (or not) within the lifetime of the FP; 

• the "editable" field value may even vary from entry to entry for the same field (see annex H, Contact List 

case). 

The "PIN protected" property bit allows the FP to protect the field against unauthorised modification by mandating PIN 
code entering before performing a save command on the field. See clause 7.4.1 1.1 for details. 

The "PIN protected" property bit itself cannot be modified by the PP (even if set to '1'). Any modification of this bit 
shall be disregarded by the FP. When creating a new entry (with a save command from PP to FP), the PP may set the 
"PIN protected" property to any value ('0' or '1'). The FP will ignore this value and set it to the desirable value. 

NOTE 5: Only editable fields (with "editable" property set to 1) may need to be 'PIN protected'. 

Other property bits shall be set correctly by the PP when using the 'save' command. 
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Error cases are described for each command in dedicated clauses (see clause 7.4.10.4). 

7.4.1 0.5.1 .1 Field 'List identifiers' 

All mandatory requirements as defined in clause 7.4.10.5.1.1 of TS 102 527-3 [18] shall apply. 

7.4.10.5.1.2 Field 'Number' 
See table 63j below. 

Table 63j: 'Number' Field 
Bits 



8 


7 1 6 1 5 1 4 1 3 


2 


1 


Octet 


Field identifier = Number 


1 


0/1 


Length (L) 


2 


0/1 


editable 


internal 


own 


X 


X 


X 


PIN 

protecte 

d 


3 


1^' digit 


4 


2™ digit 









Each digit shall be out of 30H. . .39H, 23H, 2AH, 05H, 15H. 

For octet 3, each bit indicates whether a property of the field is given (1) or not (0). In the case of 'x', the value is 
reserved for future use. 

Length: In the call lists, for incoming accepted calls, if the number information is not provided by the network to the 
FP (e.g. no CLIP or restricted CLIP received), the FP shall set the length to 1. 

'Internal' property: The 'Internal' property is used to identify internal phone numbers. It shall be set to 1 when the 
Number represents a Terminal identity number (see clause 7.4.10.5.1.2.1). It shall be set to 1 in all entries of the Internal 

Names List. 

NOTE 1 : As the call related lists do not include internal calls, this property is only set for the Internal Names List 
(see clause 7.4.10.5.8). 

'Own' property: The 'Own' property is used to indicate its own entry to the PP which consults the Internal Names List. 
The FP shall set the 'Own' property to '1' for the PP's own entry, and to '0' for all other entries in that list. It is not used 
in other lists (set to in other lists). 

The PP should prevent the user from using the entry with 'Own' property set to '1' in the Internal Names List for placing 
a call, so that the user will not attempt an internal call towards its own PP. 

If a call is nevertheless attempted by a PP towards itself, the FP shall release the call properly. 

NOTE 2: The Contact List does not use the 'Number' field, but the specific 'Contact number' field (see 
clause 7.4.10.5.1.11). 

NOTE 3: 'Editable' property is set to "0" by the FP when the field is used in the Internal Names List. 

'PIN protected' property: The 'PIN protected' property shall be set to '0', unless the field 'Number' is used: 

• as 'Dialling Prefix' field in the Line Settings List (see clause 7.4. 1 1 .4.4); 

• as 'Blocked number' field in the Line Settings List (see clause 7.4.1 1.4.7); 

• as 'Terminal id number' field in the Internal Names List (see clauses 7.4.10.5.8 and 7.4.10.5.1.2.1). 
«Text changed from TS 102 527-3 [18] (addition): 

• or as 'DTAM Number' field in the 'DTAM Settings List (see clause 7.4.36.5.2); 
End of changes» 
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In which cases, this property can be set to '0' or T by the FP depending on its security policy on those lists. See 
clause 7.4.11.1, 'PIN code' clause, for more information. 

7.4.10.5.1.3 Field 'Name' 

All mandatory requirements as defined in clause 7.4.10.5.1.3 of TS 102 527-3 [18] shall apply. 

7.4.10.5.1.4 Field 'Date and time' 

All mandatory requirements as defined in clause 7.4.10.5.1.4 of TS 102 527-3 [18] shall apply. 

7.4.10.5.1.5 Field 'Read status' 

All mandatory requirements as defined in clause 7.4.10.5.1.5 of TS 102 527-3 [18] shall apply. 

7.4.10.5.1.6 Field 'Line name' 

All mandatory requirements as defined in clause 7.4.10.5.1.6 of TS 102 527-3 [18] shall apply. 

7.4.10.5.1.7 Field 'Line id' 

All mandatory requirements as defined in clause 7.4.10.5.1.7 of TS 102 527-3 [18] shall apply. 

7.4.1 0.5.1 .8 Field 'Number of calls' 

All mandatory requirements as defined in clause 7.4.10.5.1.8 of TS 102 527-3 [18] shall apply. 

7.4.10.5.1.9 Field 'Call type' 

All mandatory requirements as defined in clause 7.4.10.5.1.9 of TS 102 527-3 [18] shall apply. 

7.4.10.5.1.10 Field 'First name' 

All mandatory requirements as defined in clause 7.4.10.5.1.10 of TS 102 527-3 [18] shall apply. 

7.4.1 0.5.1 .1 1 Field 'Contact number' 

All mandatory requirements as defined in clause 7.4.10.5.1.11 of TS 102 527-3 [18] shall apply. 

7.4.10.5.1.12 Field 'Associated melody' 

All mandatory requirements as defined in clause 7.4.10.5.1.12 of TS 102 527-3 [18] shall apply. 

7.4.10.5.1.13 Field 'Call interception' 

All mandatory requirements as defined in clause 7.4.10.5.1.13 of TS 102 527-3 [18] shall apply. 

7.4.10.5.1.14 Proprietary fields 

All mandatory requirements as defined in clause 7.4.10.5.1.14 of TS 102 527-3 [18] shall apply. 

7.4.10.5.2 "List of Supported Lists" entry fields- 
All mandatory requirements as defined in clause 7.4.10.5.2 of TS 102 527-3 [18] shall apply. 

7.4.10.5.3 "Missed Calls List" entry fields 

AH mandatory requirements as defined in clause 7.4.10.5.3 of TS 102 527-3 [18] shall apply. 
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7.4. 10.5.4 "Outgoing Calls List" entry fields 

All mandatory requirements as defined in clause 7.4.10.5.4 of TS 102 527-3 [18] shall apply. 

7.4.1 0.5.5 "Incoming Accepted Calls List" entry fields 

All mandatory requirements as defined in clause 7.4.10.5.5 of TS 102 527-3 [18] shall apply. 

7.4.1 0.5.6 "All Calls List" entry fields 

All mandatory requirements as defined in clause 7.4.10.5.6 of TS 102 527-3 [18] shall apply. 

7.4.10.5.7 "Contact List" entry fields 

All mandatory requirements as defined in clause 7.4.10.5.7 of TS 102 527-3 [18] shall apply. 

7.4.1 0.5.8 "Internal Names List" entry fields 

All mandatory requirements as defined in clause 7.4.10.5.8 of TS 102 527-3 [18] shall apply. 

7.4.10.5.9 "DECT System Settings List" entry fields 

See clause 7.4. 11.3. 

7.4.10.5.10 "Line Settings List" entry fields 

See clause 7.4. 11.4. 

7.4.1 0.5.1 1 "All Incoming Calls List" entry fields 

All mandatory requirements as defined in clause 7.4.10.5.11 of TS 102 527-3 [18] shall apply. 

7.4.1 0.5.1 2 "Line and Diagnostic Statuses List" entry fields 

See clause 7.4.34.3. 

7.4.1 0.6 List access service call and interactions with voice calls 

All mandatory requirements as defined in clause 7.4.10.6 of TS 102 527-3 [18] shall apply. 

7.4.1 0.7 Generic sequence charts for list access 

All mandatory requirements as defined in clause 7.4.10.7 of TS 102 527-3 [18] shall apply. 

7.4.1 0.8 Use case examples for list access 

All mandatory requirements as defined in clause 7.4.10.8 of TS 102 527-3 [18] shall apply. 

7.4.1 0.9 Extended list change notification 
7.4.10.9.1 General requirements 

The present 'Extended list change notification' procedure describes the use of the «List change details» IE 
accompanying a list change notification (see clause 7.4.10.2). a missed call notification (see clause 7.4.1.3) and an SMS 
Message waiting notification (see clause 7.4.1.6). 

NOTE 1: The «List change details» IE is described in clause 7.7.57 of EN 300 175-5 [5]). 
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NOTE 2: The information conveyed by an 'Extended list change indication' is therefore a superset of the 
information contained in a 'list change indication'. 

Caching. The «List change details» IE allows the PP to maintain a local copy of a list (caching) while limiting its 
accesses to the corresponding list on FP side. 

NOTE 3: A full resynchronisation of the list, although still necessary in some cases (especially when the PP is out 
of range or switched-off for some time and misses notifications), will be however needed less frequently. 

In order to update its local copy of the list, the PP may retrieve the changed entries (i.e. added and/or modified) by use 
of the 'Read selected entries' command with selection type 'selection from entry identifiers' (see clause 7.4. 10.4. 11). The 
PP may request changed entries with one or several uses of the command. 

NOTE 4: The PP should not request deleted entries. However, if it does so, the FP answers in best effort mode. 
Additionally, if all requested entries do not exist (anymore) in the list, the FP answers with a negative 
acknowledgement (see Read selected entries, in clause 7.4.10.4.11). 

When using "extended list change notifications": 

requirements of clause 7.4.10.2.1 (list change notifications/General rules in TS 102 527-3 [18]) are superseded 
by clause 7.4.10.9.2 below; this also applies in the few cases where the «List change details» IE is not used; 

NOTE 5: Clause 7.4.10.9.2 remains compatible with former clause 7.4.10.2.1 but gives more specific requirements. 

while clause 7.4.10.2.2 (in TS 102 527-3 [18]) about mandatory notifications still applies. 

NOTE 6: In other words, as soon as both the PP and the FP implement extended list change indications extended 
list change notifications are mandatory for the same lists. 

Simple list change indication. For the sake of clarity, list change indications as described in clauses 7.4.1.4 and 
7.4.10.2 are called here simple list change indications. 

NOTE 7: Simple list change indications are still used in the context of the present procedure, and are considered as 
a FP suggestion for a full resynchronisation of the list, sent to the PP. As indicated below (see table 70c in 
clause 7.4.10.9.2.2), events such as 'base reset' and 'location registration' always trigger a simple list 
change indication. Other events may trigger a simple list change indication in some cases (see 
clause 7.4.10.9.2.3). 

Extended list change indication. In addition to simple list change indication, an extended list change indication 
contains a «LIST CHANGE DETAILS» IE in the same message, with the following additional data: 

the originating PP field. This field shall always be fulfilled if all changes specified are originating from the 
same PP. If changes originate from several PPs and/or from the FP, the field value shall be set to '0' (see 
EN 300 175-5 [5], clause 7.7.57). 

two series of entry ids (one for "added and/or modified entries", and the other one for "deleted" entries). 

Use of the extended list change indication. Towards PPs that support the Extended list change indication, the FP shall 
use this extended indication format instead of the Simple list change indication format, unless the FP wants to suggest a 
full resynchronisation of the list. 

If the PP implements the 'extended list change indication' (i.e. to be able to perform list caching), it shall set the 
corresponding «TERMINAL-CAPABILITY» bit: "Support of the extended list change indication". 

Notifications shall be sent by the FP by use of the "generic event notification" procedure, together with the current 
procedure. For the indication of a list change and the values to be used in «Events notification», «List change 
details», and «Call information» information elements, consider table 70a. 
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Table 70a: Values used within {FACILITY} (or other) message for extended list change indication 



Information element 


Field within the 
information element 


Standard values 
within the field/IE 


Normative action/comment 


«Events notification» 


<Event type> 


3 


List change indication 


<Event sub typo 
<List identifier> 


All 


List identifier (see clause 7.4.10.3) 


<Event multiplicity > 


0..16 383 (note 1) 


Total number of entries in the list 
(and with the specified line id if 
applicable; see note 2) 


«List change details» 








<Originating PP> 


All 



- Terminal id number of the PP 
(when all changes originate from a 
single PP 

- Otherwise '0' (changes from several 
PPs and/or the FP) 


<ldentifiers of added and/or 
modified entries> 
<Entry id> 


1.. 16 383 


A first series of entry identifiers 
An entry id cannot be 


<ldentifiers of deleted 
entries> 

<Entry id> 


1.. 16 383 


A second series of entry identifiers 


«Call lnformatlon» 






Optional. See note 2 


<ldentifiertype> 





Line identifier 


<ldentifier sub type> 


'Line identifier for 

external call', 'Relating 

to', or 'All lines' 


'None' value is excluded 


<ldentifiervalue> 


All 


The line id value itself if present 
(absent if 'All lines' subtype is used) 


NOTE 1 : 'Event multiplicity' is coded on one or two octets. See note 1 at table 39. 

NOTE 2: «Call information» IE shall be present if and only if the list contains a line id field. This only excludes the 
three following lists: 'List of Supported Lists', 'Internal Names List, and 'DECT System Settings List'. 



7.4.10.9.2 



Sending rules 



This clause supersedes clause 7.4.10.2.1 (in TS 102 527-3 [18]) for the case an extended list change indication is used. 
Clause 7.4.10.9.1 indicates when the PP or FP can assume that extended list change indication is used. 

If extended notification is used, the present clause precises the meaning of a notification with no «List change 
details» IE. In the context of the present clause, such a notification indicates that the FP suggests a full 
resynchronisation of the list (see clause 7.4.10.9.2.3). 

The present clause also gives more specific requirements e.g. as to when a notification is sent (see clause 7.4.10.9.2.2). 



7.4.10.9.2.1 



Aggregation of notifications 



Aggregation of notifications. The notifications of several consecutive events can be aggregated in only one 
notification for all these events. 

When using the 'Extended list change indication', the FP may perform aggregation of notifications according to the 
following rules: 

Rule 1. Aggregation shall only be possible for events concerning the same list and the same line. 

Rule 2. Aggregation shall not cause an event to be notified outside of the time periods defined in clause 7.4. 10.9.2.2 
('Sending times'). In other words, clause 7.4.10.9.2.2 applies event by event whether aggregation is used or not. 

Rule 3. Whether aggregation is used or not, notification for an entry-specific event (addition, modification and deletion) 
shall always include the corresponding entry id, except if a request for full resynchronisation of the list is used by the 
FP (see clause 7.4.10.9.2.3). In other words, when a notification is sent for given line and list, and if full resync is not 
used, all concerned entry ids shall be sent to the PP, in one or several messages. 



£75/ 



92 



ETSI TS 102 527-5 V1.1.1 (2013-04) 



Rule 4. If several successive events concern the same entry and are notified together, the corresponding entry id shall be 
specified only once in the «List change details» IE. The event type to be used in the aggregated notification can be 
determined thanks to the following event type composition table: 

Table 70b: Event type composition table for aggregation of events concerning the same entry 



Previous aggregated event 
type (or 1 st event type) 


Additional event type 


Resulting aggregated event 
type (note 1 ) 


Add and/or modify 


Add and/or modify 


Add and/or modify 


Add and/or modify 


Delete 


Delete 


Delete 


Add and/or modify 


Add and/or modify (note 2) 


Delete 


Delete 


N/A 


NOTE 1 : Entry addition and modifications of an entry are not distinguished in the notification and 
are called "Add and/or modify" events, as well as allowed combinations of such events. 

NOTE 2: This combination of successive events indicates reuse of the entry id after deletion of the 
entry. It should not occur with careful handling of entry ids (cycle buffering). 



NOTE: Rule 4 is consistent with rule 3 because rule 3 only requires the presence of the entry id for individual 
events, and rule 4 requires this presence with multiplicity T' if several events share the same entry id. 



7.4.10.9.2.2 



Sending time 



The following table describes the event types that shall trigger an extended list change notification from the FP and their 
sending time. 

Table 70c: Event types triggering a 'list change indication' with or without list change details 



Event type 


Specified line 
in «CALL-INFORMATION» IE 


Targeted PPs 


Optional 

aggregation 

(note 1) 


Mandatory sending 
time 


Entry created, modified, 
or deleted by PP in any 
list 


list with line Id 
field 


line id subtype and value 
(if any value) 
of the concerned entry 
(note 2) 


At least all PPs 
attached to the 
line id (notes 3, 
4) 


Over the session, 
only for entries 
sharing the same 
list id and line id 


Any time from 
beginning of session 
until end of session + 
<CC.NG.02> 


list with no line 
id field 


None (no «CALL- 
INFO» IE) 


All PPs (note 3) 


Over the session 


Incoming, outgoing, or 
missed call (note 5) 


Line where the call occurred 


At least all PPs 
attached to the 
line where the 
call occurred 
(notes 3, 4) 


Possible if calls 
where on the same 
line and their time 
intervals allow a 
common sending 
time (see sending 
time rules) 


Any time from 
beginning of call until 
end of call + 
<CC.NG.02> 


Entry created, modified, 
or deleted by FP in any 
list (note 12) 


list with line id 
field 


line id subtype and value 
(if any value) 
of the concerned entry 
(note 2) 


At least all PPs 
attached to the 
line id (notes 3, 
4) 


Only for entries 
sharing the same 
list id and line id 


Any time from event 
time to event time + 
<GC.NG.02> 


list with no line 
id field 


None (no «CALL- 
INFO» IE) 


All PPs (note 3) 


Possible for entries 
of the same list 


Base reset (notes 6, 7) 


list with line id 
field 


Line for which the 
notification is sent (note 9) 


At least all PPs 
attached to the 
line (note 4) 


No aggregation 
No details 
(notell) 


When FP reset is 
completed 


list with no line 
id field 


None (no «CALL- 
INFO» IE) 


All PPs 


Location registration 
(note 8) 


list with line id 
field 


Line for which the 
notification is sent 
(note 10) 


ThePP 
performing 
location 
registration only 


No aggregation 
No details 
(notell) 


When location 
registration is 
successfully 
completed 


list with no line 
id field 


None (no «CALL- 
INFO» IE) 
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Event type 



Specified line 
in «CALL-INFORIVIATION» IE 



Targeted PPs 



Optional 

aggregation 

(note 1) 



Mandatory sending 
time 



NOTE 1 : As indicated in clause 7.4.1 0.9.2.1 , aggregation is optional and e.g. may therefore cover only part of a LiA session 

changes. 
NOTE 2: If several events are notified together (aggregation), they shall have the same line id subtype and value, or the 

same subtype only if 'All lines' subtype is used (value field is then absent). 
NOTE 3: The PP may ignore the «LIST-CHANGE-DETAILS» IE if it does not cache the list. 
NOTE 4: FP is allowed to send it to all PPs, independently of attachments. If the PP is not attached to the specified line, it 

may ignore the notification. 
NOTE 5: These events correspond to a special case of FP initiated entry creation. 

NOTE 6: This event triggers notifications for each list for which notification is mandatory (see clause 7.4.1 0.2.2). 
NOTE 7: If a list is lost (i.e. erased from memory) as a result of the base reset, a 'list change indication' is sent with <Event 

multiplicity> field set to '0'. 
NOTE 8: E.g. after PP getting into range again or PP switched on again. 

NOTE 9: One notification is issued per line and broadcasted to at least all PPs attached to the line. 
NOTE 10: One notification is issued per line the PP is attached to. 
NOTE 1 1 : No «List change details» IE is sent here to the PP, so that a full resynchronisation of the list is systematically 

suggested (in the case where the PP caches the list). 
NOTE 12: This excludes the case of entry addition in call lists (handled in the previous row). This includes list management 

from a web interface (e.g. DECT settings management), subscription registration and de-registration of a PP (also 

impacting the Internal Names List), etc. 



7.4.10.9.2.3 



Full resynchronisation of a list 



By sending a list change indication with no associated «List change details» IE, the FP suggests a full 
resynchronisation of a list to the PP. However, depending on PP implementation or on the current circumstances, the PP 
can ignore this suggestion from the FP. 

The FP shall at least suggest a full resynchronisation in the following cases: 

• Location registration of a PP (full resynchronisation systematically suggested to the concerned PP). 

• Base reset (full resynchronisation systematically suggested to all PPs). 
The FP may suggest a full resynchronisation in the following cases: 

• Too many entries have been changed in the meantime. FP shall only use this possibility if: 

either the number of changed entries would necessarily require more than one {FACILITY} message; 

or the number of changed entries exceeds 50 % of the total number of entries in the list. 

EXAMPLE: If 2 entries out of 4 have changed, the second criterion does not apply. 
If 3 entries out of 4 have changed, the second criterion applies. 

7.4.1 1 DECT system and line settings 

7.4.1 1 .1 DECT system and line settings considerations 

All mandatory requirements as defined in clause 7.4.n.l of TS 102 527-3 [18] shall apply. 

7.4.1 1 .2 Interactions between registration, attachments of handsets and lists 

All mandatory requirements as defined in clause 7.4.11. of TS 102 527-3 [18] shall apply. 

7.4.1 1 .3 DECT System Settings List 

The following text replaces clause 7.4.11.3 of TS 102 527-3 [18] and shall apply (see tagged changes). 
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The following entry fields are defined for the (singular) DECT system list entry. 

«Text changed from TS 102 527-3 [18] (modification, Field "Base manual transmit power control" is added): 
Table 71 : Entry fields for the (singular) DECT System Settings list entry 



Field 
identifier 


Field 


Length 
constraint 


Default 

value 

(notel) 


Base reset 
impacted 


Normative action/comment 


Clause 


01H 


Current PIN code 


= 5 


YES/MD 


MD 


Before a PIN protected field 
(i.e.: a new PIN code) can be 
saved an edit/save of the 
current PIN code is required 


7.4.11.3.1 


02H 


Clock master 


= 2 


YES/MD 


MD 


Defines the entity which sets 
date an time for the DECT 
system (PP or FP) 


7.4.11.3.2 


03H 


Base reset 


= 2 


YES 


YES 


Sets settings back to default 
factory values 


7.4.11.3.3 


04H 


FP IP address /type 


= 1 


MD 


MD 


DHCP or static 


7.4.11.3.4 


05H 


FP IP address / value 


>1 


MD 


MD 


Editable only for static IP 
address 


7.4.11.3.5 


06H 


FP IP address / 
subnet mask 


> 1 


MD 


MD 


Editable only for static IP 
address 


7.4.11.3.6 


07H 


FP IP address / 
gateway 


> 1 


MD 


MD 


Only for static IP address 


7.4.11.3.7 


08H 


FP IP address / DNS 
server 


> 1 


MD 


MD 


Only for static IP address 
'FP IP address / DNS server is 
a multiple instance field 


7.4.11.3.8 


09H 


FP version / Firmware 
version 


> 2, < 20 


YES/MD 


NO 


Software version of the FP 


7.4.11.3.9 


OAH 


FP version / Eeprom 
version 


> 1 , < 20 


MD 
(note 2) 


NO 


Eeprom version of the FP 


7.4.11.3.10 


OBH 


FP version / Hardware 
version 


> 2, < 20 


YES/MD 


NO 


Hardware version of the FP 


7.4.11.3.11 


OCH 


Emission mode 


>2 
(note 3) 


YES/MD 


MD 


Bitmap for 

activating/deactivating the 'No 
Emission mode', etc. 


7.4.11.3.12 


ODH 


New PIN code 


= 5 


YES/MD 


MD 


Allows modification of the PIN 
code 


7.4.11.3.13 


OEH 


Base manual transmit 
power control 


= 2 


MD 


MD 


Bitmap for 

activating/deactivating the 
Part 5 'Base manual transmit 
power control' mode 


7.4.11.3.14 


NOTE 1 : For optional or conditional fields, the default value only applies when the field is implemented. 
NOTE 2: The field "Eeprom version" is mandatory but may be empty (length = 1 ) if the system does not use 

EEPROM. 
NOTE 3: For the present revision of the present document, the length is always 2 (extensible field). 



End of changes» 

Field identifiers from OEH to 80H are reserved for further standardization and shall not be used. 

Field identifiers from 81H to FFH are reserved for proprietary fields and may be freely used by implementers for coding 
of proprietary features. 

Default value: it is the value of the setting when product is manufactured: 

• "YES" means that a default value is standardized. See corresponding setting clause definition. 



• "MD" means that a default value shall be provided by the manufacturer (could also be empty by setting the 
length to 1). 

• "YES/MD" means that a default value shall be provided by the manufacturer, which shall not be empty. 
"Base reset" impacted: describes the impact of the "Base reset" setting on this particular setting: 

• "YES" means setting is reset to default value when "Base reset" setting is activated. 
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• "NO" means setting is not impacted by "Base reset" setting. 

• "MD" means manufacturer defines if the setting is impacted or not by the "Base reset" setting. 

7.4.11.3.1 Field 'Current PIN code' 

All mandatory requirements as defined in clause 7.4.11.3.1 of TS 102 527-3 [18] shall apply. 

7.4.11.3.2 Field 'Clock master' 

All mandatory requirements as defined in clause 7.4.11.3.2 of TS 102 527-3 [18] shall apply. 

7.4.11.3.3 Field 'Base reset' 

All mandatory requirements as defined in clause 7.4.11.3.3 of TS 102 527-3 [18] shall apply. 

7.4.1 1 .3.4 Field 'FP IP address / type' 

All mandatory requirements as defined in clause 7.4.11.3.4 of TS 102 527-3 [18] shall apply. 

7.4.1 1 .3.5 Field 'FP IP address / value' 

All mandatory requirements as defined in clause 7.4.11.3.5 of TS 102 527-3 [18] shall apply. 

7.4.1 1 .3.6 Field 'FP IP address / subnet mask' 

AH mandatory requirements as defined in clause 7.4.11.3.6 of TS 102 527-3 [18] shall apply. 

7.4.1 1 .3.7 Field 'FP IP address / gateway' 

All mandatory requirements as defined in clause 7.4.11.3.7 of TS 102 527-3 [18] shall apply. 

7.4.1 1 .3.8 Field 'FP IP address / DNS server' 

All mandatory requirements as defined in clause 7.4.11.3.8 of TS 102 527-3 [18] shall apply. 

7.4.1 1 .3.9 Field 'FP version / Firmware version' 

All mandatory requirements as defined in clause 7.4.11.3.9 of TS 102 527-3 [18] shall apply. 

7.4.1 1 .3.1 Field 'FP version / Eeprom version' 

All mandatory requirements as defined in clause 7.4.11.3.10 of TS 102 527-3 [18] shall apply. 

7.4.1 1 .3.1 1 Field 'FP version / Hardware version' field 

All mandatory requirements as defined in clause 7.4.11.3.11 of TS 102 527-3 [18] shall apply. 

7.4.11.3.12 Field 'Emission mode' 

All mandatory requirements as defined in clause 7.4.11.3.12 of TS 102 527-3 [18] shall apply. 

7.4.11.3.13 Field 'New PIN code' 

All mandatory requirements as defined in clause 7.4.11.3.13 of TS 102 527-3 [18] shall apply. 
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7.4.11.3.14 



Field 'Base manual transmit power control' 



The 'Base manual transmit power control' field allows to activate or deactivate the 'Green Features' on the FP from one 
of the PPs. It shall be coded as in table 71a. 



Bits 



Table 71a: Base manual transmit power control' field 



8 


7|6|5|4|3|2|1 





Field identifier = Base manual transmit power control 


0/1 


Length (L) 


0/1 


Editable 


X 


X 


X 


X 


X 


PIN 

protected 


0/1 


reserved 


BTPC 



Octet 
1 
2 
3 



'PIN protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect the 'Base manual 
transmit control' field against unauthorised modification, depending on its security policy. 

Bits 2 to 6 of octet 3 are reserved for further standardization and shall be set to "0". 

Base manual transmit control mode bitmap (octet 4): 

This field is a bitmap octet group. 



Bits 7 6 5 4 3 21 

X X X X X X 
X X X X X X 1 



Meaning 

'Base manual transmit power control' mode deactivated 
'Base manual transmit power control' mode activated 



Bit 1: 'Base manual transmit power control' mode (BTPC). If bit 1 is set, the FP shall activate the 'Base manual 
transmit power control' mode MAC service [NG1.A.4]. Otherwise the FP shall deactivate it. 

Bits 2 to 7 of octet 4 are reserved for further standardization and shall be set to "0". 

7.4.12 Calling line identity restriction (CLIR) 

All mandatory requirements as defined in clause 7.4.12 of TS 102 527-3 [18] shall apply. 

7.4.13 Call forwarding (external calls) 

All mandatory requirements as defined in clause 7.4.13 of TS 102 527-3 [18] shall apply. 

7.4.14 DTMF handling 

All mandatory requirements as defined in clause 7.4.14 of TS 102 527-3 [18] shall apply. See ITU Q.23 [i.8] and ITU 
Q.24 [i.9] for further information. 

7.4.15 Tones provision 

All mandatory requirements as defined in clause 7.4.15 of TS 102 527-3 [18] shall apply. See ITU E.180 [i.lO] and ITU 
E.180 Supplement 2 [i. 1 1] for further information. 

7.4.16 Headset management 

All mandatory requirements as defined in clause 7.4.16 of TS 102 527-3 [18] shall apply. 

7.4.17 UTF-8CNIP 

All mandatory requirements as defined in clause 7.4.17 of TS 102 527-3 [18] shall apply. 
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7.4.18 Location registration after re-locl< 

All mandatory requirements as defined in clause 7.4.18 of TS 102 527-3 [18] shall apply. 

7.4.19 PT alerting using pattern signalling 

All mandatory requirements as defined in clause 7.4.19 of TS 102 527-3 [18] shall apply. 

7.4.20 Date and Time recovery 

All mandatory requirements as defined in clause 7.4.20 of TS 102 527-3 [18] shall apply. 

7.4.21 Void 

NOTE: Descriptions of new features and procedures specific to NG-DECT part 5 start at clause 7.4.32. This 

leaves room for features and procedures that may be designed in the future but which are not specific to 
Part 5. That is, the new features that will apply to both Part 3 and Part 5, because they are considered 
important to both parts, will not be interleaved but will be in contiguous subclauses. 

7.4.22 Void 

NOTE: Descriptions of new features and procedures specific to NG-DECT part 5 start at clause 7.4.32. This 

leaves room for features and procedures that may be designed in the future but which are not specific to 
Part 5. That is, the new features that will apply to both Part 3 and Part 5, because they are considered 
important to both parts, will not be interleaved but will be in contiguous subclauses. 

7.4.23 Void 

NOTE: Descriptions of new features and procedures specific to NG-DECT part 5 start at clause 7.4.32. This 

leaves room for features and procedures that may be designed in the future but which are not specific to 
Part 5. That is, the new features that will apply to both Part 3 and Part 5, because they are considered 
important to both parts, will not be interleaved but will be in contiguous subclauses. 

7.4.24 Void 

NOTE: Descriptions of new features and procedures specific to NG-DECT part 5 start at clause 7.4.32. This 

leaves room for features and procedures that may be designed in the future but which are not specific to 
Part 5. That is, the new features that will apply to both Part 3 and Part 5, because they are considered 
important to both parts, will not be interleaved but will be in contiguous subclauses. 

7.4.25 Void 

NOTE: Descriptions of new features and procedures specific to NG-DECT part 5 start at clause 7.4.32. This 

leaves room for features and procedures that may be designed in the future but which are not specific to 
Part 5. That is, the new features that will apply to both Part 3 and Part 5, because they are considered 
important to both parts, will not be interleaved but will be in contiguous subclauses. 

7.4.26 Void 

NOTE: Descriptions of new features and procedures specific to NG-DECT part 5 start at clause 7.4.32. This 

leaves room for features and procedures that may be designed in the future but which are not specific to 
Part 5. That is, the new features that will apply to both Part 3 and Part 5, because they are considered 
important to both parts, will not be interleaved but will be in contiguous subclauses. 
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7.4.27 Void 

NOTE: Descriptions of new features and procedures specific to NG-DECT part 5 start at clause 7.4.32. This 

leaves room for features and procedures that may be designed in the future but which are not specific to 
Part 5. That is, the new features that will apply to both Part 3 and Part 5, because they are considered 
important to both parts, will not be interleaved but will be in contiguous subclauses. 

7.4.28 Void 

NOTE: Descriptions of new features and procedures specific to NG-DECT part 5 start at clause 7.4.32. This 

leaves room for features and procedures that may be designed in the future but which are not specific to 
Part 5. That is, the new features that will apply to both Part 3 and Part 5, because they are considered 
important to both parts, will not be interleaved but will be in contiguous subclauses. 

7.4.29 Void 

NOTE: Descriptions of new features and procedures specific to NG-DECT part 5 start at clause 7.4.32. This 

leaves room for features and procedures that may be designed in the future but which are not specific to 
Part 5. That is, the new features that will apply to both Part 3 and Part 5, because they are considered 
important to both parts, will not be interleaved but will be in contiguous subclauses. 

7.4.30 Void 

NOTE: Descriptions of new features and procedures specific to NG-DECT part 5 start at clause 7.4.32. This 

leaves room for features and procedures that may be designed in the future but which are not specific to 
Part 5. That is, the new features that will apply to both Part 3 and Part 5, because they are considered 
important to both parts, will not be interleaved but will be in contiguous subclauses. 

7.4.31 Void 

NOTE: Descriptions of new features and procedures specific to NG-DECT part 5 start at clause 7.4.32. This 

leaves room for features and procedures that may be designed in the future but which are not specific to 
Part 5. That is, the new features that will apply to both Part 3 and Part 5, because they are considered 
important to both parts, will not be interleaved but will be in contiguous subclauses. 

7.4.32 Contact number and name matcining on outgoing call 
7.4.32.1 Contact number and name matching on outgoing call 

The present procedure applies to a PP and the FP involved in any external outgoing voice calls (first or parallel). This 
procedure shall be used by the FP in order to inform the PP of the remote party number and name in the following 

cases: 

• Case 1 (Contact List matching): the dialled digits sent by the PP correspond to an existing entry of the 
Contact List. 

• Case 2 (contact provision by network): the remote party is forwarded or re-routed by the network to another 
number with possible associated name (e.g. the remote party activated a call forwarding). 

NOTE 1 : This procedure may also be used for internal calls, especially to indicate the remote party handset number 
and name in the case of an internal general call. But this out of the scope of the present document. 

Case 1: Contact List matching 

When proceeding an outgoing call (first or parallel), the FP shall search in the Contact List if the dialled digits match an 
entry in this list. If so, the FP shall send to the PP within any applicable CC message (see below): 

• a «Called Party Name» IE filled with the contact 'name' and 'first name'. 



£75/ 



99 



ETSI TS 102 527-5 V1.1.1 (2013-04) 



If the 'Name' and 'First name' fields of Contact List entry found are both empties, no «Called Party Name» IE shall 
be sent at all. 



PP 



CC-SETUP 



«BASIC SERVICE=88» «CODEC-LIST» 
CC-CONNECT 



« CODEC-LIST » 
CC-INFO 



« MULTI-KEYPAD = dialed digits» 
CC-INFO 



« CALL-INFORMATION = CS Call proceeding » 
CC-INFO 



« CALLED PARTY NAME = contact name, 
contact first name » 



FP 



If dialed digits match a 
phone number in a contact 
list entry 



Figure 80-1 : Contact List matching on outgoing call (early {CC-CONNECT} use case) 

NOTE 2: The Call Control message sequence in figure 80-1 should be understood as an example. The real 

sequences may also contain different Call Control messages, or Call Control messages in another order, 
or Call Control messages with other contents. 

For the contact name indication, the format to be used in all messages is shown in following table 75-1: 
Table 75-1 : Values added within any applicable CC message when Contact List matching 



«Called party 
name» 








<Used alphabet> 


UTF-8 




<Screening indicator> 


User-provided 




<Called party name> 


All 


Name of Contact List entry 


<Called party first 
name> 


All 


First name of Contact List entry 



Case 2: contact provision by network 

When proceeding an outgoing call (first or parallel), if the call is forwarded or re-routed by the remote party to an other 
party, the FP shall send to the PP within any applicable CC message (see below): 

• A «Called Party Number» IE filled with the "forwarded-to" number provided by the network (number to 
which the remote party has been forwarded to). 

• Additionally, if provided by the network, a «Called Party Name» IE with the name corresponding to this 
new number. <Screening indicator> shall be set to 'Network provided' to indicate the called party name origin. 

NOTE 3: The current use case 2 may apply after case 1 occurred, for a first call or for a second outgoing call. In 
other words, the PP will be ready to receive twice remote party information for any outgoing call. 

NOTE 4: In the very specific case where the forwarded-to number matches a phone number in a Contact List entry, 
a «Called Party Name» IE with the name corresponding to this new number will be used as in use 
case 1. The <Screening indicator> field will be set to 'User provided'. 

NOTE 5: According to Generic Access Profile (GAP) (see EN 300 444 [11] clause 8.10), the « Called Party 

Number » information element is no longer used to send en-bloc dialling in the PP to FP direction. It 
can be used in combination with the « Called Party Name » information element to send called party 
details in the FP to PP direction. 
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PP 



{CC-SETUP} 



«BASIC SERVICE=88» «CODEC-LIST» 
{CC-CONNECT} 



« CODEC-LIST » 
{CC-INFO} 



« MULTI-KEYPAD = dialed digits» 
{CC-INFO} 



FP 



« CALL-INFORMATION = CS Call proceeding » 
{CC-INFO} 



« CALLED PARTY NUMBER = forwarded-to number » 
{CC-INFO} 
« CALLED PARTY NAME = forwarded-to contact name » 



Call is forwarded in the 
network 



If information provided by 
the network 



Figure 80-2: Contact provision by the networit (early {CC-CONNECT} use case) 

NOTE 6: The Call Control message sequence in figure 80-2 should be understood as an example. The real 

sequences may also contain different Call Control messages, or Call Control messages in another order, 
or Call Control messages with other contents. 

For number and name indications, the format to be used in all messages is shown in following tables 75-2 and 75-3. 

Table 75-2: Values added within any applicable CC message 
for the number when provided by the network 



Information 
element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Called party 
number» 








<Number Type> 


Unknown 




<Numbering plan 
identification> 


Unknown 




<Called party address> 


All 


"Forwarded-to" number transmitted by 
the network 



Table 75-3: Values added within any applicable CC message 
for the name when provided by the network 



«Called party 
name» 








<Used alphabet> 


UTF-8 




<Screening indicator> 


Network provided 


Called party name information 
provided by the network 


<Called party name> 


All 


Name provided by the network 


<Called party first 
name> 


All 


First name provided by the network (if 
any) 



Common requirements to both cases: 

These lEs shall be sent together with the call id of the concerned call: 

• For a 'non early { CC-CONNECT } ' implementation of the FP: either included in the { CC-C ALL-PROC } 
{CC- ALERTING}, {CC-CONNECT}, or {CC-INFO} message. 

• For an 'early {CC-CONNECT}' implementation of the FP: in a {CC-INFO} message following the 
{CC-CONNECT}. 



£75/ 



101 



ETSI TS 102 527-5 VI. 1.1 (2013-04) 



Therefore, called party name and number shall be sent by the FP in one of the following stages: 

between 'CS call proc' status indication and 'CS call alerting' status indication; or 

between 'CS call alerting' status indication and 'CS call connect' indication; or 

after 'CS call connect' status indication. 

When both number and name are sent to the PP, on PP side it is sufficient to display the name. It is optional to display 
both. 

NOTE 7: Called party name and number might not fit in a single message; in that case one or more additional 
{CC-INFO} message(s) are used. 

7.4.33 Contact number and name matching on incoming call 

The present procedure applies to a PP and the FP involved in an external incoming voice call (first or parallel), for 
which at least a CLIP is received from the network. This procedure shall be used by the FP in order to populate the 
CNIP directed to the PP with data from a matching Contact List entry. 

Matching Contact List entry. A matching Contact List entry is an entry for which one of the included telephone 
numbers matches the CLIP received from the network during an incoming call. 

FP requirements. In the case of an incoming call for which at least a CLIP value is received, the FP shall behave as 
follows: 

If a matching entry exists in the Contact List, the FP shall use the 'Name' and 'Firstname' field values in order 
to create an artificial CNIP and send it to the PP. This requirement only applies if the 'Name' and 'Firstname' 
fields are not both empty. The artificial CNIP shall be preferred over the CNIP received from the network (if 
any). See table 75-4 for the parameters used for an artificial CNIP. 

If there is no matching entry in the Contact List, or if there is one, but both the 'Name' and 'Firstname' fields 
are empty, the FP shall use the CNIP received from the network (if any), with all received parameters used 'as 

is'. 

Otherwise, the FP shall not send any CNIP to the PP. 

PP requirements. The PP shall handle the artificial CNIP as any other CNIP. In other words, all PP requirements 
applicable for a regular CNIP that are stated in other related procedures (see clause 6.10, GAP. N. 34 feature) shall also 
apply for the artificial CNIP. 

Table 75-4: Values used for an artificial CNIP populated by the FP with the Contact List 



Information 
element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Calling party 
name» 








<Presentation lndlcator> 


Presentation allowed 


(note) 


<Screenlng lndicator> 


User provided, verified and 
passed 


(note) 


<Calllng party name> 


All 


(note) 


NOTE: If a CNIP Is received from the network, this network originating CNIP and Its parameters shall be Ignored, 
as the CNIP sent to the PP is constructed here from the CLIP and a matching Contact List entry. 



7.4.34 Line and diagnostic information 
7.4.34.1 General requirements 

The 'Line and diagnostic information' feature allows the FP to inform PPs of the status (and status changes) of 'elements' 
located on FP side, by modifying entries in the Line and Diagnostic Statuses List, and by sending notifications to the 
PPs about these changes. 
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The 'Line and diagnostic statuses' list shall always contain the current value of a status, and shall not store former values 
of this status. The Line and Diagnostic Statuses List is read-only. 

Status change notification. A 'Generic events notification' shall be used for the purpose of notifying the PP of any 
status change. Details about this notification are given in clause 7.4.1.5. 

Related line. A status may relate (or not) to a line. 

• When relating to a line, the status value shall be stored in the list entry with corresponding line id field value. 
When notifying a line relating status change, the corresponding line-id shall be indicated in the <Event 
multiphcity> field included in the «E VENTS -NOTIFICATION»IE. 

• When not relating to a line, the status value shall be stored in the list entry with line id field value 'None'. 
When notifying a non line relating status change, the <Event multiplicity> field value is don't care. 

PP side requirements: 

A diagnostic information may target the end-user, the PP, or the after-sales service. 

Diagnostic information display. When a line or diagnostic information is directed at the end-user, the PP should — after 
consultation of the 'Line and diagnostic information' list if needed — display it on the screen of the handset (especially 
in idle mode), in order to inform the user as directly as possible. The exact information displayed is out of the scope of 
the present document. It may for example take the form of a displayed text or icon. 

The diagnostic information that is mandatory to display is listed in table 75-5 of clause 7.4.34.2. 

The PP does not need to store any diagnostic information for other purposes than displaying it. 

EXAMPLE: A PP with display constraints could keep in memory more (still valid) information than it is able to 
display at a given time. 

Remote consultation (list access mode). The PP shall give access to all supported fields of the Line and Diagnostic 
Statuses List. In other words, the user (or after-sales service) is able to retrieve all available information. MMI 
presentation of the information is left up to the implementer. 

Virtual Line and Diagnostic Statuses List. The PP may implement a virtual Line and Diagnostic Statuses List by hiding 
from the user the entries concerning lines the PP is not attached to. However, the default behavior is that all the 
diagnostic information is shared among all PPs independently of PP's attachments to lines. 

NOTE: On the contrary, displayed icons should only concern lines the PP is attached to. 

FP side requirements: 

The FP shall implement diagnostic information for all mandatory elements (see clause 6.10 and 7.4.34.2). More 
specifically, the FP shall provide: 

• one list entry for every line existing in the system; 

• an additional list entry for statuses relating to the system and not to a specific line. For this entry: 

Line id value 'None' shall be used. 

Only the 'Line id', 'OK status' and 'Diagnostic error status' fields are relevant. Therefore, for the other 
fields, the FP shall use the smallest allowed length (see clause 7.4.34.3, table 75-6, 'length constraint') 
and the PP shall ignore the field value. 

Events triggering notification. The FP shall send diagnostic indications to the PP at times described in table 75-5, 
column 'Status change triggered by/at' (see clause 7.4.18.2). 



Targeted PPs. The subset of PPs receiving the diagnostic indication is described in clause 7.4.1.5. 

Sorting of the list: The Line and Diagnostic Statuses List shall be sorted by default using the "Line id" field (see 
clause 7.4.10.3). If default sorting is used, the non line relating list entry (with line id='None' = '127') shall therefore be 
the last entry in the list. 
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Commands: The 'Edit entry', 'Save entry', 'Delete entry', 'Delete list' commands shall not be invoked by any PP on the 
read-only 'Line and Diagnostic Statuses List, and the FP shall answer them with negative acknowledgement with reject 
reason "procedure not allowed" (see clause 7.4.10.4.9). 

PIN code: In the scope of the present document, no field of the list is PIN protected. 

7.4.34.2 Exposed diagnostic information 

The elements managed by the 'Line and diagnostic information' feature are summarized in the following table 75-5. 
Table 75-5: List of diagnosed elements, diagnostic info and PP display status 



Field 
(status type) 


status change triggered by/at 


Notification type 
(note 6) 


PP Display 
Status 
(notel) 


FP 
Status 


Line use status 

(see also 

clause 7.4.1.5.2.1) 


- at the beginning of the first external incoming or 
outgoing call on that line 

- at the end of the last external call on that line 


Line use indication 



(note 2) 


M 


Handset use status 

(see also 

clause 7.4.1.5.2.2) 


- when any handset becomes in-use for an external call 
on the considered line or no longer in-use on that line 


Handset use 
indication 





M 


Call Forwarding statuses 

(CPU, CFNA, and/or 

CFB) 

(see also 

clause 7.4.1.5.2.3) 




Diagnostic indication 
(line related) 




(note 5) 


M 


OK status (line related) 

(see also 

clause 7.4.1.5.2.3) 


- each time an error occurs (or ceases to occur) on the 
considered line 


Diagnostic indication 
(line related) 
(see note 4) 




(notes 2, 3) 


M 


Diagnostic error status, 

line related 

(see also 

clause 7.4.1.5.2.3) 


- an error on a specific line for which a cause has been 
identified 

- the error ceases to occur 


OK status (non line 

related) 

(see also 

clause 7.4.1.5.2.3) 


- each time an error occurs (or ceases to occur) on the 
system 


Diagnostic indication 
(non line related) 
(see note 4) 





M 


Diagnostic error status, 
non line related 
(see also 
clause 7.4.1.5.2.3) 


- an error occurring on the system for which a cause has 
been identified 

- the error ceases to occur 


NOTE 1 : This status for PP corresponds to the on-screen display in idle mode. The referenced notes specify display 

recommendations or other requirements. 
NOTE 2: If this field is supported by PP: in a multiple line environment, the immediately displayed information should 

represent a combination of the statuses of the lines the PP is attached to. 
NOTE 3: If this field is supported by PP: at a minimum, a global 'Down' icon should be displayed if none of the lines the PP 

is attached to is in status 'line is up'. The user can however access (e.g. via an advanced settings menu) the exact 

status of each of the lines the PP is attached to. 
NOTE 4: Only diagnostic indications may be either line related or non-line related. A line related diagnostic indication is sent 

at least to all PPs attached to the line for which the status changes. The PP may ignore a notification concerning a 

line it is not attached to. 
NOTE 5: If this field is supported by PP, at a minimum, a global 'Activated' icon should be displayed if at least one CF type 

(CPU, CFNA, CFB) is activated on at least one of the line. 
NOTE 6: Line related diagnostic indications are also sent at PP location registration and in the case of a new PP 

attachment to a line (see clause 7.4.1 .5.2.3) independently of any status change. 
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7.4.34.3 Line and Diagnostic Statuses List 

The Line and Diagnostic Statuses List is a read-only list used to inform the PP of the current status of various 'elements' 
on FP side. 

The following entry fields are defined for a Line and Diagnostic Statuses List entry in table 75-6. 

Table 75-6: Entry fields for a Line and Diagnostic Statuses List entry 



Field 
identifier 


Field 


Length 
constraint 


Default 
value 


Normative action/comment 


Clause 


01H 


Line id 


>=2 


YES/MD 


Concerned line 

'None' value is used for a non line related 

(or 'system') diagnostic error (see note) 


7.4.34.3.1 


02H 


OK status 


>=2 


YES/MD 


Working status of the indicated line or of 
the system. 

Changes relating to this status are only 
partially notified 


7.4.34.3.2 


03H 


Line use status 


>=2 


YES/MD 


Change and value of the status are 
notified 


7.4.34.3.3 


04H 


Handset use status 


>=2 


YES/MD 




7.4.34.3.4 


05H 


Call Forwarding status 


>=2 


YES/MD 


Includes statuses for CFU, CFNA, CFB 


7.4.34.3.5 


06H 


Diagnostic error status 


>=2 


YES/MD 


Line-relating or non-line relating status. If 
non line related, the status is repeated for 
each line for convenience 


7.4.34.3.6 


NOTE: For the list entry using 'None' value, fields with ids 03H, 04H and 05H are not relevant and shall be 

ignored (and possibly not requested) by the PP. The FP shall use the smallest allowed length for these 
fields, as indicated by the 'Length constraint' column. 



7.4.34.3.1 Field 'Line id' 

See 'Line id' field in "List access service" feature, clause 7.4.10.5.1.7. This field shall always contain a specific line id. 



7.4.34.3.2 



Field 'OK status' 



The 'OK status' field indicates whether the considered entity (i.e. a line, or the system) is working ('up') or not working 
('down'). 

When used for a line, the 'OK status' down value indicates that an error is occurring and that this line is not 
working as a result. 

When used for the system, the 'OK status' down value indicates that an error is occurring that affects the use of 
a service usually provided by the system, but distinct from the use of a line. 

EXAMPLE 1 : If a Wide Area Network error prevents access to data related services such as firmware upgrade 
(see TS 102 527-4 [i.5], firmware upgrade might be impossible, while all lines are still working. 

EXAMPLE 2: If some lists (e.g. the Contact List) is located in a network and this network becomes inaccessible, 
the system OK status might be down, while all lines are still working. 

NOTE 1 : If a single event affects both the use of one or of several lines, and of a system service, both types of OK 
status (line related and system related) could be 'down' at the same time (with the same or possibly 
different diagnostic error type and number). 
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The 'OK status' field shall be coded as in table 75-7. 

Table 75-7: 'OK status' field 
Bits 



8 


7 


6 


5 14 13 


2 


1 


Octet 





Field identifier = OK status 


1 


0/1 


Length (L) 


2 


0/1 


Editable 
=0 


X 


X 


X 


X 


X 


X 


3 


0/1 


OK status 


4 



OK status (octet 4): 



Bits 



7654321 

0000000 
0000001 
0000010 
000001 1 



Meaning 

down 
registering 
initializing 
up 



The FP shall only notify status changes to and from 'up' value to the PP. All other status transitions shall not be notified 
by the FP. The values 'registering' and 'initializing' are provided for possibly detailing transient states of a line being 
setup on network side (i.e. they are not to be used for the system OK status). 

NOTE 2: The OK status and diagnostic error status fields are related. When the line (resp. system) is not working, 
the 'diagnostic error status' possibly informs the PP of the error cause if the FP could identify it. See 
clause 7.4.34.3.6 for more information and examples. 

7.4.34.3.3 Field 'Line use status' 

The 'Line use status' field shall be coded as in table 75-8. 



Table 75-8: 'Line use status' field 



Bits 



8 


7 


6 1 5 1 4 1 3 1 2 1 1 


Octet 





Field identifier = Line use status 


1 


0/1 


Length (L) 


2 


0/1 


Editable 
=0 


X 


X 


X 


X 


X 


X 


3 


0/1 


Line use status 


4 



Line use status (octet 4): 



Bits 



7654321 

0000000 
0000001 
0000010 



Meaning 

Line is idle (no active call at all) 

Line is in-use (but additional calls can be placed) (note 1)) 

Line or system is busy (note 2) 



NOTE 1 : 'Line is in-use' indicates that the user is still able to place a call on the line. The line is 'in-use', but it 
supports more than one call simultaneously (and the line is not in 'single call mode', see 
TS 102 527-3 [18], clause 7.4.1 1.4.8), but neither the line nor the system is busy. 

NOTE 2: A line is busy if the user is not able to place a call on it because the maximum number of calls that can be 
placed simultaneously on the line has been reached. However, the system may be busy before this 
maximum is reached (because of internal calls or of calls on other lines). 

EXAMPLE: Handset 1 if engaged in call 1 and handset 2 in call 2 on line 1 in multiple call mode, and octet 4 is 
'lO'B (as the system or the line only support two simultaneous calls). When handset 1 hangs up, 
octet 4 becomes 'Ol'B. When handset 2 hangs up, octet 4 becomes 'OO'B. 
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7.4.34.3.4 Field 'Handset use status' 

The 'Handset use status' field shall be coded as in table 75-9. 

Table 75-9: 'Handset use status' field 
Bits 



8 


7 


6 1 5 1 4 1 3 1 2 1 1 


Octet 





Field identifier = Handset use status 


1 


0/1 


Length (L) 


2 


0/1 


Editable 
=0 


X 


X 


X 


X 


X 


X 


3 


1 


Number of handsets using the line 


4 


0/1 


Handset use bitmap 


5 


0/1 






1 


Handset use bitmap (continued) 


5n 



Number of handsets using the Une (octet 4) 

This field contains the number of handsets using the line. 

NOTE 1: This number may be greater or equal to two for a multiple call line. 

Handset use bitmap (octet group 5) 

This bitmap octet group contains one flag per handset (flag for handset number 1 is in bit position '1', etc.), indicating 
when set that the handset is using the line. 

NOTE 2: The structure of this bitmap is similar to the 'Attached handsets' field (see 102 527-3 [18], 
clause 7.4. 11.4.3). 

NOTE 3: In principle, a handset using a line is attached to this line. However, this may not be true for call transfer, 
call deflection, etc. 

NOTE 4: Internal calls are not taken into account for the handset use bitmaps. 

The 'handset use status' only takes into account external calls, and, when set, means that the handset is engaged in at 
least one external call on the specified line. 

NOTE 5: If all 'handset use status' bitmaps are considered together (one for each line), all these bitmaps allow to 

draw the complete handset to line use relationship. However, the use multiplicity (if one handset uses the 
same multiple call line several times) is not given. 

7.4.34.3.5 Field 'Call Forwarding status' 

The 'Call Forwarding status' field shall be coded as in table 75-10. 

Table 75-10: 'Call Forwarding status' field 
Bits 



8 


7 


6 1 5 1 4 1 3 1 2 1 1 


Octet 





Field identifier = Call Forwarding status 


1 


0/1 


Length (L) 


2 


0/1 


Editable 
=0 


X 


X 


X 


X 


X 


X 


3 


0/1 


CFU status 


4 


0/1 


CFNA status 


5 


0/1 


CFB status 


6 



'Call Forwarding Unconditional' status subfield (octet 4): 



Bits 7 6 5 4 3 21 

0000000 
0000001 



Meaning 

'Call Forwarding Unconditional' is 'deactivated' 
'Call Forwarding Unconditional' is 'activated' 
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'Call Forwarding on No Answer' status subfield (octet 5): 



Bits 7 6 5 4 3 21 

0000000 
0000001 



Meaning 

'Call Forwarding on No Answer' is 'deactivated' 
'Call Forwarding on No Answer' is 'activated' 



'Call Forwarding on Busy subscriber' status subfield (octet 6): 



Bits 7 6 5 4 3 21 

0000000 
0000001 



Meaning 

Call Forwarding on Busy subscriber is 'deactivated' 
Call Forwarding on Busy subscriber is 'activated' 



The field is related to a specific line. 



7.4.34.3.6 



Field 'Diagnostic error status' 



The 'Diagnostic error status' field shall be used in relationship with the 'OK status', in order to indicate a cause identified 
by the FP for the occurring error. 

The yes/no bit of the 'diagnostic error status' shall indicate whether a cause is identified or not for the error indicated by 
the 'down' value of the 'OK status'. More generally, the allowed combinations of this bit with the 'OK status' up/down 
bit value are shown in table 75-1 1 below. 

Table 75-11 : Relationship between 'OK status' and 'Diagnostic error status' 



OK status 
up/down bit 


Diagnostic error status 
yes/no bit 


Comment 


up 


yes 


Forbidden 


up 


no 


No error occurring 


down 


yes 


Occurring error with identified cause 


down 


no 


Occurring error with no identified cause 



As indicated in clause 7.4.34.3.2 (Field 'OK status'), the 'OK status' and related 'Diagnostic error status' both either 
relate to a specific line or to the system. The defined diagnostic error type and error number values may be used for 
lines as well as for the system. 

When the OK status and diagnostic error status fields are used for the system: 

These statuses refer to the working status of services (e.g. data related services) normally rendered by the FP. 

The working status of these services is in principle independent of the working status of the lines themselves. 

There is a single instance of these statuses for all services rendered by the system. The system OK status 
should therefore be down as soon as one of these services is down. 

The 'Diagnostic error status' field shall be coded as in table 75-12. 

Table 75-12: 'Diagnostic error status' field 
Bits 



8 


7|6|5|4|3|2|1 


Octet 





Field identifier = Diagnostic error status 


1 


0/1 


Length (L) 


2 


0/1 


Editable 
=0 


no/yes 


X 


X 


X 


X 


X 


3 


0/1 


Diagnostic error type 


4 


0/1 


Diagnostic error number 


5 



No/ yes bit (bit 6 of octet 3): 

Bit 6 of octet 3 shall indicate when set to 'yes' that a cause has been identified for the error. 

When set to 'no' (no error or no cause identified for the error), the diagnostic error type and error number shall 
both be '0' ('Unknown error'). 
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When set to 'yes', the error type shall be either 'Network error' or 'Local error'; however, the error number may 
still be '0' (i.e. respectively either 'Unknown network error' or 'Unknown local error') indicating that no further 
information is available. 

NOTE 1 : When bit is reset from 'yes' to 'no', it is not allowed to continue indicating the previous error type and 
number. 

Bits 7 6 5 4 3 21 Meaning 

X X X X X X No error or no identified cause (no) 

X 1 X X X X X Identified cause for the occurring error (yes) 

NOTE 2: 'No error or no identified cause (no)' is used in two cases: if the 'OK status' for the corresponding entity is 
'up' (no error) or if it is 'down' but with no identified cause. 

Diagnostic error type subfield (from octet 4): 

Bits 7 6 5 4 3 21 Meaning 

Unknown error (note) 

1 Network error 

10 Local error 

All other values reserved 

NOTE 3: The 'Unknown error' value is only used if the 'No/yes' bit is set to 'No' (no error or no identified cause). In 
that case the error number is also set to 'Unknown error' as indicated below. 

Diagnostic error number subfield for error type 'Unknown error' (from octet 5): 

Bits 7 6 5 4 3 21 Meaning 

Unknown error 

All other values reserved 

Diagnostic error number subfield for error type 'Local error' (from octet 5): 

Bits 7 6 5 4 3 21 Meaning 

Unknown local error (note) 

1 Local Area Network (LAN) error 

10 Local Area Network (LAN) level 2 error (e.g. Ethernet error) 

1 1 Local Area Network (LAN) level 3 error (e.g. IP error) 

10 Cable error 

10 1 Modem or Home Gateway error 

All other values reserved 

NOTE 4: 'Unknown local error' value is used if the only available information is that the error is local. 

Diagnostic error number subfield for error type 'Network error' (from octet 5): 

Bits 7 6 5 4 3 21 Meaning 

Unknown network error (note) 

1 Wide Area Network (WAN) error 

All other values reserved 

NOTE 5: 'Unknown network error' value is used if the only available information is that the error is on network 
side. 

PP requirements: 

The PP shall support all error numbers (i.e. not crash as a result of receiving any of them). When an error occurs, the 
PP: 

should at least be able to display the error type in idle with no user intervention; 

may display the error number or should otherwise refer the user to the 'Line and Diagnostic Statuses List' for 
more information. 

The PP should inform the user about whether the error is line related or not. For line related errors, the PP should 
indicate the concerned line to the user. 



£75/ 



109 



ETSI TS 102 527-5 VI. 1.1 (2013-04) 



FP requirements: 

The FP shall store the last occurring error in this field. 

The FP should support as many error numbers as possible. The FP shall at least support the 'Unknown error', 'Network 
error' and 'Local error' error types. 

NOTE 6: A network error as well as a local error may be line related or not. 

For the interpretation of the error number the FP may then refer the user to the 'instructions for use' document and/or 
after-sales service. 

See table 75-13 for examples of combined uses of the 'OK status' and 'Diagnostic error status' fields. 

Table 75-13: Examples of combined uses of the 'OK status' and 'Diagnostic error status' fields 



Example with a system with 3 lines (line 0, line 1 and line 2) (see note) 


FP implementation specific breakdown 
(example) 


Comment 


N° 


Example Line and diagnostic list contents 


Use 
(note) 


Comment 


- 


System: OK status, (yes/no, type, number) 
Line 0: OK status, (yes/no, type, number) 
Line 1: OK status, (yes/no, type, number) 
Line 2: OK status, (yes/no, type, number) 


- 


Line and diagnostic list extract format used in the examples 
below. Content of OK status and diagnostic error status is 
shown for the system and for each line. 


1 


System: up, (no, 0,0) 

Line 0: up, (yes, network, WAN) 

Line 1: up, (no, 0,0) 
Line 2: up, (no, 0,0) 


forbidden 


Forbidden because if a diagnostic exists for the line, then the 
line is necessarily down. 


2 


System: up, (no, 0,0) 
Line 0: down, (yes, 0, 0) 

Line 1: up, (no, 0,0) 
Line 2: up, (no,0,0) 


forbidden 


Forbidden because for a 'yes' diagnostic error status the 
value for (type,number)= (O,0)=(unknown, unknown) cannot 
be used. Only the error number can be possibly in that 
case, but the type shall be either 'network' or 'local'. 


3 


System: up, (no, 0,0) 

Line 0: down, (yes, network, WAN) 

Line 1: up, (no, 0,0) 
Line 2: up, (no,0,0) 


allowed 


Line is down because of a WAN error. Everything else is 
working. 


4 


System: up, (no, 0,0) 
Line 0: down, (yes, network, WAN) 
Line 1 : down, (yes, network, WAN) 
Line 2: down, (yes, network, WAN) 


allowed 


Line related WAN error occurs on every line. 

No error is diagnosed at system level: if the FP offers non line 

related services, these services are working. 


5 


System: up, (no, 0,0) 

Line 0: down, (yes, network, WAN) 

Line 1: down, (no, 0,0) 
Line 2: up, (no, 0,0) 


allowed 


Line is down because of a WAN error. 

Line 1 is down for an unknown reason (undiagnosed error). 

Everything else is working. 


6 


System: down, (yes, network, WAN) 

Line 0: up, (no, 0,0) 
Line 1: up, (no, 0,0) 
Line 2: up, (no, 0,0) 


allowed 


A system error occurs that affects a service offered by the 
system, but no line is affected by the error. 


7 


System: down, (yes, network, WAN) 
Line 0: down, (yes, network, unknown) 

Line 1: up, (no, 0,0) 
Line 2: up, (no,0,0) 


allowed 


- At least one service offered by the system is not working 
and the reason for this error is known (WAN error). 

- Line is down because of a network error that is not further 
specified (error number='unknown network error'). 

- Everything else is working. 


8 


System: down, (yes, network, WAN) 

Line 0: down, (no, 0,0) 
Line 1: down, (no, 0,0) 
Line 2: down, (no, 0,0) 


allowed 


- At least one service offered by the system is not working 
and the reason for this error is known. 

- None of the lines are working, but the reason for this is 
unknown. 


9 


System: down, (yes, local. Cable error) 
Line 0: down, (yes, network, WAN) 
Line 1: up, (no, 0,0) 
Line 2: down, (yes, local, LAN level 2) 


allowed 


- At least one service offered by the system is not working 
and the reason for this error is known. 

- Line and 2 are down for various reasons. 


NOTE: The allowed or forbidden status is related to the FP choice made above (except for example n° 1). 
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7.4.34.4 Diagnostic indication 



When sending a diagnostic related notification to the PP, the FP shall use a 'Generic events notification' of type 
'diagnostic indication'. Diagnostic indications are described in clause 7.4.1.5 (see also EN 300 175-5 [5], clause 7.7.55). 

7.4.35 Short Message Service 
7.4.35.1 General requirements 

The purpose of the "Short Message Service" feature is to allow the use on a DECT system of a network-side short 
message service. It allows the PP to receive notifications for incoming SMS messages, to send SMS messages, to store 
SMS messages on the FP and to browse them from the PP. 

For a DECT system with multiple lines, there can be one SMS service per line. The parsing of SMS messages received 
from the network (i.e. from a given line) is out of scope of the feature. 

The "Short Message Service" feature uses several lists on the FP to store SMS messages, and relies on the "List Access" 
feature for allowing the PP to manage messages. Incoming SMS are handled using one list (the Incoming SMS List, 
while the outgoing SMSs are handled using three lists 

Incoming SMSs. The handling of incoming SMSs uses the Incoming SMS List only. See clause 7.4.35.2 for more 
details. 

Outgoing SMSs. The handling of outgoing SMSs makes use of three lists. See clause 7.4.35.3 for more details. 

When a FP implements the "Short Message Service" feature, it shall support at least one entry per list. 

SMS settings. The SMS settings shall be available per SMS service, and shall be stored in the "SMS Settings List". 

NOTE 1: The SMS Settings List indicates the line on which an SMS service is available. 

Incoming SMS content encoding. The FP shall always store incoming SMSs in UTF-8. See clause 7.4.35.2 for more 
information. 

PP control over network side outgoing SMS content encoding. The PP may control the SMS content encoding used 
on network side if several encodings are available for the SMS service. This allows the PP to control the SMS size on 
the network especially for pricing purposes. See 7.4.35.3 (outgoing SMS encoding) for more information. 

Local outgoing SMS content encoding. The local encoding used for an outgoing SMS in the SMS lists (SMS content 
field) may differ from the network encoding. In that case, only UTF-8 may be used locally. See clause 7.4.35.3. 

FP SMS capability. If the FP implements the SMS feature, the SMS lists shall appear in the List of Supported Lists 
(see clause 7.4.10.5.2). To check whether a FP is supporting SMS, a PP shall check if the SMS lists are supported or 
not. 

Private SMS boxes. Some networks allow the creation of up to 10 SMS boxes within the DECT system. Such boxes 
are attached to a line and are addressable thanks to the addition of one digit at the end of the line number. This 
additional digit is a kind of box id that may be used for sending or receiving SMSs from/to that box on the given line. 
The "Short Message Service" feature does not cover the use of private SMS boxes but does not prevent it. 

Private SMS boxes could be implemented on FP side by exposing only the relevant entries to the used PP during the 
Read entries. Search entries and Edit entry commands. 

NOTE 2: Private SMS boxes could imply implementation of a proprietary user authentication mechanism. A FP 
implementing private SMS boxes should therefore allow authentication deactivation by configuration so 
that the SMS feature can still be used from non compatible PPs implementing the SMS feature. 

NOTE 3: In a one to one relationship between PPs and boxes, user authentication might be avoided. 

NOTE 4: A master PP or user could possibly access all entries by authenticating itself as a master. 
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Short and long SMS messages. On some networks, the length limitation of SMSs could be worked around by 
concatenating short messages (see concatenated short messages in TS 123 040 [i.l4]). On such networks, so-called 
'long SMSs' are made up of several short messages (also known as the message 'parts' in the present document) that may 
arrive independently at the FP. From the present standard perspective however, there is no distinction between short and 
long SMSs: every entry in the incoming messages list shall contain a complete SMS message (short or long). 

NOTE 5: In other words, the collection and management of short messages at the FP-to-network interface for 
rebuilding the so-called long SMSs is out of scope of the present document. 

NOTE 6: This explains the terminology of a 'partially arrived SMS' used in the present document for the case the 
message parts of a long SMS do not arrive at the same time. 

Reading of SMS content. As the text payload of a single SMS message might take up to 640 bytes, it will be 
impossible for low cost PPs to read the entire field in a single read request. 

NOTE 7: When a PP displays an SMS message to the user, it could read an amount of bytes which more or less 
corresponds to the size of the screen (i.e. possibly much less than the actual SMS content size). 

The PP may limit the size of the 'SMS content' field received, by using several times the 'Read selected entries' 
command (using selection type 'selection from entry id with range') instead of the plain 'Read entries' command. When 
using this command, the PP is able to request only a range of the content bytes within the SMS content field. 

Read status. The Incoming SMS List has a 'Read status' field. It is the PP responsibility to update this field thanks to 
the 'mark entries request' field value of the 'Read entries'/'Search entries' commands. 

7.4.35.2 Incoming SMS handling 

Incoming SMSs are handled using the following single list: 

• Incoming SMS List. Messages arriving from the line to the FP, and from there to the PPs 

Incoming SMS content encoding. The FP shall always use UTF-8 for the local encoding of an incoming SMS. The FP 
shall therefore perform a translation of the SMS content into UTF-8 (if not used in the network) before storing it in the 
Incoming SMS List. 

Reading a partially received SMS. If the FP stores a partially received SMS in the Incoming SMS List, and therefore 
makes them available to the PP, the 'Read status' field shall nevertheless remain 'unread' until the SMS is fully received. 

If a PP happens to read such a partially received SMS, the FP shall ignore the 'mark entries request' field value of the 
used 'Read entries' command. The 'mark entries request' shall only be taken into account if the command is received at a 
time where the SMS is fully received. 

7.4.35.3 Outgoing SMS handling 

Outgoing SMSs are handled using the following three lists: 

Draft SMS List. Messages being edited and not sent yet to the line. 

Outgoing SMS List. Messages pending to be sent to the line. A message remains in this list until the FP 
successfully sends it to the line. 

Sent SMS List. Messages sent from one of the PPs to the FP, and already sent to the line 

PP control over network side outgoing SMS content encoding. The PP may control the SMS content encoding used 
on network side if several encodings are available for the SMS service (but may alternatively leave this control to the 
FP). This allows SMS size control by PP especially for pricing purposes. The PP is informed about the available 
encodings by the FP through the SMS Settings List ('Allowed SMS character encodings and variants' field). 

More specifically: 

The PP chooses the encoding and encoding variant used for the new outgoing SMS using field 'Network side 
SMS encoding' of the 'Draft SMS' or 'Outgoing SMS' lists (depending on which list is used to create the SMS). 

The PP possibly leaves the choice to the FP by using the 'Unknown' value as indicated in 

clause 7.4.35.5. LL 
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The FP uses the encoding and encoding variant chosen by the PP towards the network or uses the most 
appropriate one if the PP did not make the choice. 

NOTE 1 : By choosing the encoding and encoding variant used on network side itself, the PP is able to control the 
size of the SMS on the network side. When TS 123 038 [19] encoding is used, this ability can be used to 
warn the user about the number of short SMSs needed to encode the outgoing SMS on network side, 
especially for pricing purposes. 

Local outgoing SMS content encoding. The local encoding used for an outgoing SMS in the SMS lists (and therefore 
over the air) shall be chosen as follows: 

if the PP selects an encoding to be used on network side in the ' Network side SMS encoding field' (i.e. if 
'Unknown' value is NOT used), the local encoding shall be equal to that network side encoding; 

if the PP leaves control over network side encoding to the FP (i.e. 'Unknown' value is used), the local encoding 
shall be UTF-8. 

Requesting translation of an outgoing SMS local encoding. A PP may request translation of an SMS local encoding 
by editing the 'Network side SMS encoding' field (using edit/save entry). The allowed new values usable in the 
translation request are described in the following table 75-14. 

NOTE 2: A PP may do so prior to reading the SMS content (e.g. in the 'Sent SMS List'), or in order to further edit it 
(e.g. in the 'Draft SMS List'). 

NOTE 3: Requesting translation of the local SMS encoding also modifies the PP selection of a network side 
encoding. 

In order to request SMS encoding translation, the PP shall only insert the ' Network side SMS encoding' field (and no 
other field of the list) in the save entry command. 

The FP shall then modify the SMS content field of the corresponding list accordingly. 

Table 75-14: SMS encoding translation possible requests 



Network side SMS encoding 
before translation 


Inserted 'Network side SIMS 
encoding' (translation request) 


Action taken by FP 


Unknown 


PP selection (not 'Unknown', not 
UTF-8) 


SMS content translated from UTF-8 
into PP selected encoding 


Unknown 


PP selection =UTF-8 


Nothing done 


PP selection (not 'Unknown', not UTF-8) 


Unknown 


SMS content translated from PP 
selected encoding into UTF-8 


PP selection =UTF-8 


Unknown 


Nothing done 


PP selection 1 (not 'Unknown', not UTF-8) 


PP selection 2 (not 'Unknown', not 
UTF-8), different from PP selection 1 


'Procedure not allowed' returned 
(note) 


Any value 


Same value as before translation 


'Procedure not allowed' returned 


NOTE: The FP is only required to be able to perform an encoding translation to or from UTF-8. 



Writing of an SMS. When writing an SMS in the draft list, and especially for storing intermediate versions of the SMS 
in the draft list, the PP may use the 'write entry' command with write type 'write from entry id with range' (see 
clause 7.4.10.4.12). This command allows the PP to write only a range of bytes in the 'SMS content' field, leaving other 
parts of the SMS content untouched. The write entry command can only be used between the 'edit entry' command 
(locking the entry) and the save command (unlocking the entry) and leaves the entry locked. 

Outgoing SMS lifecycle. For the successive outgoing SMS states (including the concerned SMS list, and events 
triggering state transitions), and related notifications to the PPs, the following diagram (Figure 80-3) and table 
(Table 75-15) apply. 
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Ready SMS 
created 



SMS in Outgoing list 

(SMS sending request 
received) 



Sending to network 
pending 



SIVIS entry 
deieted manuaiiy 



<CC.NG.03> 
reactied 



sending to 
network 
failure 



FP 

manages to 

tnandover 

SMS to 

network 

within 

timeout... 



SMS in Sent list 

(SMS sent to network) 




End-to-end 
delivery failure 



SMS entry 
deleted manually 



SMS entry 
deleted manually 



NOTE 1 : 



NOTE 2: 
NOTE 3: 



NOTE 4: 



NOTE 5: 



An SMS is at the same time in a high-level state (SMS in xyz list) and in one of the related sub-states. 
Manual deletion of an SMS may occur from any sub-state in principle (this is why the corresponding arrow 
starts at high-level state). 

Events relating to SMS lifecycle (entry addition, modification, or deletion) are represented with arrows. 
"A", "M", and "D" annotation of an event means that the event triggers a list change notification towards the 
PP (for an entry addition, modification, and deletion, respectively). The annotation is included in the higher- 
level state relating to the list for which the notification is sent. All but one events trigger only one 
notification. See table 75-15 below for more information. 

For the Outgoing SMS List, no notification is sent if the SMS is sent within the "sending to network" timeout 
(<CC.NG.03>). If the SMS can be sent after the timeout, two notifications are sent (Outgoing SMS List 
entry deletion-i-Sent SMS List addition). 

No "list change notification" is sent for end-to-end failure/success events (SMS remains unchanged in the 
Sent SMS List). A "notification SMS" may be added to the Incoming SMS List for the purpose of informing 
the user. 

Figure 80-3: Outgoing SIVIS successive states 



SMS entering the Outgoing SMS List (user sets the 'SMS sending request' flag). When the PP user makes the 
decision to sent a ready SMS message: 

If the ready SMS is stored in the 'Draft SMS List', the PP shall set the 'SMS sending request' flag of the 
corresponding entry to 'send' value, in order to indicate to the FP that the message shall be sent. 

If the ready SMS is NOT stored in the 'Draft SMS List' (i.e. the SMS was edited outside of the draft list on a 
PP side editing tool), the PP shall add the ready SMS to the 'Outgoing SMS List' directly. 

Upon reception of the save command setting the flag, the FP shall immediately move the SMS from the 'Draft SMS 
List' to the 'Outgoing SMS List'. 

SMS entering the Sent SMS List. Upon successful sending of the message to the network, the FP shall move the SMS 
entry from the 'Outgoing SMS List' to the 'Sent SMS List'. 

NOTE 4: Successful sending of the message to the network does not mean end to end successful sending to the 
targeted end user, but only that the FP could handover the SMS to the network. 

Sending of list change notification for outgoing SMS. The following table 75-15 shall be taken into account. 
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Table 75-15: Sending of list change indication 



List change notification 


Draft SMS List 


Outgoing SMS List 


Sent SMS List 


Entry addition 


YES 


NO (note 2) 


YES (note 4) 


Entry modification 


YES 


NO (read only list) 


NO (read only list) 


Entry deletion 


YES (see note 1) 


NO (note 2) 


YES (note 5) 


Sending to network timeout 
(<CC.NG.03>) reached 
(failure) 


N/A 


YES (as if added; see note 3) 


N/A 


Sending to network success 
after timeout 


N/A 


YES (as if deleted; see 
note 3) 


N/A 


End to end delivery success 


N/A 


N/A 


NO (note 6) 


End to end delivery failure 


N/A 


N/A 


NO (note 6) 


NOTE 1 : Two types of events cause an entry deletion from the Draft SMS List: a manual deletion of the draft SMS 

before it is sent, or an "SMS sending request" moving the SMS to the Outgoing SMS List. 
NOTE 2: Entry addition and deletion in the Outgoing SMS List are not notified if SMS is successfully sent within 

"sending to network timeout" (transient entry). 
NOTE 3 If the FP fails to send the SMS to the network (timeout reached), a list change notification is sent as if the 

entry was added to the list; this does not exclude however that the FP later on succeeds in sending the SMS; 

in that case, the entry deletion is also notified. 
NOTE 4: List change indication indicates here that the SMS was successfully handed over to the network (SMS enters 

the Sent SMS List). 
NOTE 5: List change indication indicates here that the SMS was manuaWy deleted from the Sent SMS List. 
NOTE 6: End to end success or failure do not change the entry in the Sent SMS List. The FP may notify these events (if 

it is aware of them) by creating a dedicated "notification SMS" in the Incoming SMS List, or by any other 

means. 



7.4.35.4 SMS settings 
7.4.35.4.1 SMS Settings List 

The entry field identifiers as from Table 75-16 are defined for the SMS Settings List. 

Table 75-16: Entry fields for an SMS Settings List entry 



Field 
identifier 


Field 


Length 
constraint 


Default 
value 
(note) 


Base 

reset 

impacted 


Normative action/comment 


List change 

notification 

FP status 


Clause 


01H 


SMS service id 


>3 


YES/MD 


NO 


SMS service identifier 


M 


7.4.35.4.2.1 


02H 


Line id 


>3 


YES/MD 


NO 


Line used by the SMS service 


M 


7.4.10.5.1.7 


03H 


Enable SMS 


>2 


YES/MD 


NO 


Enables the SMS feature (YES 
/NO) 


M 


7.4.35.4.2.2 


04H 


Max SMS size 


>2 


YES/MD 


NO 


Maximum SMS message size 
supported by the FP 


M 


7.4.35.4.2.3 


05H 


SMSC Send 
Server 


>1 


MD 


NO 


Short Message Service Centre 
Send Server 


M 


7.4.35.4.2.4 


06H 


SMSC Receive 
Server 


> 1 


MD 


NO 


Short Message Service Centre 
Receive Server 


M 


7.4.35.4.2.5 


07H 


SMS delivery 
report 


>2 


YES/MD 


NO 


SMS delivery report (YES or 
NO) 


M 


7.4.35.4.2.6 


08H 


SMS validity 
period 


= 2 


YES 


NO 


SMS validity period chosen by 
user; default value is 24 hours 


M 


7.4.35.4.2.7 


09H 


Allowed SMS 
character 
encodings and 
variants 


>2 


YES/MD 


NO 


SMS character encoding used 
for that SMS service 


M 


7.4.35.4.2.8 


NOTE: For optional or conditional fields, the default value only applies when the field is implemented. 
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7.4.35.4.2 



7.4.35.4.2.1 



SMS settings fields 



Field 'SMS service id' 



The SMS service identifier allows the PP and FP to associate an outgoing SMS to the service it is intended to be sent to, 
or an incoming SMS to the service is was received from. See table 75-17 below. 



Table 75-17: 'SMS service id' field 



Bits 



8 


7 


6 1 5 1 4 1 3 


2 


1 1 


Field identifier = SIVIS service id 


0/1 


Length (L) | 


0/1 


editable 


X 


X 


X 


X 


X 


PIN 

protected 


0/1 


SMS service Id value 



Octet 
1 
2 
3 



For octet 3, each bit indicates whether a property of the field is given (1) or not (0). In the case of 'x', the value is 
reserved for future use. 

'PIN protected' property: The 'PIN protected' property allows the FP to protect (or not) the 'SMS service id' field 
against unauthorized modification, depending on its security policy. 



7.4.35.4.2.2 Field 'Enable SMS' 

The 'Enable SMS' field shall be coded as in table 75-18. 

Table 75-18: 'Enable SMS' field 
Bits 



8 


7 


6 1 5 1 4 1 3 


2 


1 


Field identifier = Enable SMS 


0/1 


Length (L) 


0/1 


Editable 


X 


X 


X 


X 


X 


PIN 

protected 


Value 



Octet 
1 
2 
3 



'PIN protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect (or not) the 'Enable 
SMS' field against unauthorized modification, depending on its security policy. 

'Value' octet (octet 4). The 'Value' octet shall be 30H or 31H. 30H stands for SMS feature Disabled, 31H for SMS 
feature enabled. 



7.4.35.4.2.3 Field 'Max SMS size' 

The 'Max SMS size' field shall be coded as in table 75-19. 

Table 75-19: 'Max SMS size' field 
Bits 



8 


7 


6 1 5 1 4 1 3 


2 


1 


Octet 


Field identifier = Max SMS size 


1 


0/1 


Length (L) 


2 


0/1 


Editable 


X 


X 


X 


X 


X 


PIN 

protected 


3 


Value 


4 



'PIN protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect (or not) the 'Max 
SMS size' field against unauthorized modification, depending on its security policy. 

'Value' octet (octet 4). The 'Value' subfield shall contain the maximum SMS size (in octets) supported by the FP. It 
may be coded on several octets. In that case octet 4 shall be the most significant byte. 
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7.4.35.4.2.4 



Field 'SMSC Send Server' 



The 'SMSC Send Server' field is numeric field which hold the SMS send server number and shall be coded as in 
table 75-20. 



Bits 



Table 75-20: Field 'SMSC Send Server' 



8 


7 1 6 1 5 1 4 1 3 


2 


1 


Octet 


Field identifier = SMSC Send Server 


1 


0/1 


Length (L) 


2 


0/1 


Editable 


X 


X 


X 


X 


X 


PIN 

protected 


3 


1^' digit 
2"" digit 


4 
5 



'PIN protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect (or not) the 'SMSC 
Send Server' field against unauthorized modification, depending on its security policy. 

'Digit' octets (start from octet 4) hold the SMSC Send server number. The SMSC Send server field is number field and 
can have the digits in ASCII format, each digit shall be out of 30H. . .39H, 23H, 2AH, 05H, 15H. 



7.4.35.4.2.5 Field 'SMSC Receive Server' 

The 'SMSC Receive Server' field shall be coded as in table 75-21. 

Table 75-21 : 'SMSC Receive Server' field 
Bits 



8 


7 1 6 1 5 1 4 1 3 1 2 


1 


Field identifier = SMSC Receive Server 


0/1 


Length (L) 


0/1 


Editable 


X 


X 


X 


X 


X 


PIN 

protected 


1^' digit 
2"' digit 



Octet 
1 
2 
3 

4 
5 



'PIN protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect (or not) the 'SMSC 
Receive Server' field against unauthorized modification, depending on its security policy. 

'Digit' octets (start from octet 4) hold the SMSC Receive server number. The SMSC receive server field is number 
field and can have the digits in ASCII format, each digit shall be out of 30H. . .39H, 23H, 2AH, 05H, 15H. 

7.4.35.4.2.6 Field 'SMS delivery report' 

The 'SMS delivery report' field shall be coded as in table 75-22. 

Table 75-22: Field 'SMS delivery report' 

Bits 8 |7 |6 |5 |4 |3 |2 |i ^Octet 

1 
2 
3 



8 


7 |6 |5 |4 |3 |2 


1 


Field identifier =SMS delivery report 


0/1 


Length (L) 


0/1 


Editable 


X 


X 


X 


X 


X 


PIN 

protected 


Value 



'Length' octet (octet 2): the value of the length (L) indicator shall be > '2'. The field shall always contain the property 
bits octet and the 'Value' octet. 
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'PIN protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect (or not) the 'SMS 
delivery report' field against unauthorised modification, depending on its security policy. 

'Value' octet (octet 4). The 'Value' octet shall be 30H or 31H: 

Value '30H' stands for 'Delivery report NOT requested'. If 'Value' is 30H, the FP shall not inform PPs of any 
delivery report received from the SMSC. The FP may, however, choose to request a delivery report anyway 
from the SMSC for other internal purposes. 

Value '3 IH' stands for 'Delivery report requested'. If 'Value' is 3 IH, the FP shall request a delivery report from 
the SMSC when sending the outgoing message. On receipt of any delivery report from the SMSC the FP shall 
inform PPs of the SMS delivery success or failure by inserting a dedicated report SMS in the 'Incoming SMS 
List'. In the case of failure, the report SMS shall indicate the failure cause. 

If the PP supports the SMS feature, the PP shall make the 'Value' accessible to the user. 



7.4.35.4.2.7 Field 'SMS validity period' 

The 'SMS validity period' field shall be coded as in table 75-23. 

Table 75-23: 'SMS validity period' field 

|7 |6 |5 |4 |3 |2 |1 



Bit: 



8 



Field identifier =SIVIS validity period 


0/1 


Length (L) 


0/1 


Editable 


X 


X 


X 


X 


X 


PIN 

protected 


Validity period encoding value 



I Octet: 

1 
2 
3 



Length octet (octet 2): The value of the length (L) indicator shall be equal to '2'. The field shall always contain property 
bits octet and the 'Validity period value' octet. 

'PIN protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect (or not) the 'SMS 
validity period' field against unauthorised modification, depending on its security policy. 

'Validity period encoding value' octet (octet 4). The 'Validity period encoding value' octet shall be set according to 
the following table 75-24 (see also ES 201 912 [i.l5], clause B.2.2.19). 

Table 75-24: Validity period encoding 



Octet 4 range 
(value) 


Encoded validity 
period 


Unit 


Validity period granularity 


Oto 143 


(value + 1) x5 


minute 


5 minutes intervals up to 12 hours 


144to167 


12 X (value -143) x 0,5 


hour 


Half an hour intervals up to 24 hours 


168to196 


value- 166 


day 


One-day intervals up to 30 days 


197 to 255 


value- 192 


week 


One-week intervals up to 63 weeks 



The FP shall use the value set by the PP user when sending any outgoing SMS to the SMSC. 

If the PP supports the SMS feature, the PP shall allow the user to select the desired validity period. 

Default value: The default value shall be 167 (representing 24 hours). 
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7.4.35.4.2.8 



Field 'Allowed SMS character encodings and variants' 



The purpose of the 'Allowed SMS character encodings and variants' field is to inform the PP of the allowed encoding(s) 
and variants (if any) that are allowed on the network side for the given SMS service. 

The PP shall use this information only when it wants to have control over the encoding used for an outgoing SMS when 
sent to the network (see also clause 7.4.35.3, section 'PP control over network side outgoing SMS content encoding'). 

This field shall be coded as follows in table 75-25 below. 



Bit: 



Table 75-25: 'Allowed SMS character encodings and variants' field 

|8 |7 |6 |5 |4 |3 |2 |l lOctet: 



Field identifier = Allowed SMS character encodings and variants 


1 


0/1 


Length (L) 


2 


0/1 


Editable 


X 


X 


X 


X 


X 


PIN 

protected 


3 


0/1 


Length of allowed encoding 1 and variants (LI ) 


4 


0/1 


SMS character encoding value 


4+1 


0/1 


Allowed encoding variant 1 




0/1 






0/1 


Allowed encoding variant m-| 


4+L1 






0/1 


Length of allowed encoding n and variants (Ln) 


L+2-Ln 


0/1 


SMS character encoding value 


L+3-Ln 


0/1 


Allowed encoding variant 1 




0/1 






0/1 


Allowed encoding variant mp 


L+2 



'PIN protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect (or not) the 'SMS 
character encoding' field against unauthorised modification, depending on its security policy. 

'SMS character encoding value' octet (octet 4). Any instance of the 'SMS character encoding value' subfield indicates 
to the PP an encoding that can be used for outgoing SMSs using the given SMS service. 

Bits 7 6 5 4 3 21 Meaning 

Reserved (see note 1) 

1 TS 123 038 / GSM 7 bit (see note 2) 

10 TS 123 038 / GSM 8 bit (see note 2) 

11 TS 123 038 / UCS-2, big-endian (see note 2) 

10 UTF-8 

All other values reserved. 

NOTE 1 : This value can only be used by the PP in field 'Network side SMS encoding' and cannot be used in the 
present field. See clause 7.4.35.5.1.1. 

NOTE 2: When this encoding is used, the PP should be aware that outgoing SMSs could be split by the network 
into short SMSs of 140 bytes. It may also warn the user for pricing reasons. 

The FP shall at least support TS 123 038 / GSM 7 bit default character encoding (i.e. with the "default alphabet table" 
and the "default alphabet extension table" defined in TS 123 038 [19]). See below 'Allowed encoding variant for SMS 
character encoding TS 123 038 / GSM 7 bit' for more information. 

'Allowed encoding variant' for SMS character encoding TS 123 038 / GSM 7 bit. Any instance of this subfield 
indicates to the PP a language supported by the FP. The PP uses this information to build a TS 123 038 [19] compliant 
GSM 7 bit encoding variant as a combination of two language specifications: one for the 'alphabet table' and the other 
one for the alphabet extension table (see clause 7.4.3.5.1.1). See table 75-26 below. 
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Table 75-26: "Allowed encoding variant" encoding 



Value 


Meaning 





GSIVI 7 bit, default (note 1) 


1H 


GSM 7 bit, Turkish (notes 2, 3) 


2H 


GSIVI 7 bit, Spanish (notes 2, 3) 


3H 


GSM 7 bit, Portuguese (notes 2, 3) 


4H 


GSM 7 bit, Bengali (notes 2, 3) 


5H 


GSM 7 bit, Gujarati (notes 2, 3) 


6H 


GSM 7 bit, Hindi (notes 2, 3) 


7H 


GSM 7 bit, Kannada (notes 2, 3) 


8H 


GSM 7 bit, Malayalam (notes 2, 3) 


9H 


GSM 7 bit, Oriya (notes 2, 3) 


10H 


GSM 7 bit, Punjabi (notes 2, 3) 


11H 


GSM 7 bit, Tamil (notes 2, 3) 


12H 


GSM 7 bit, Telugu (notes 2, 3) 


13H 


GSM 7 bit, Urdu (notes 2, 3) 


14H 
toFFH 


Reserved by TS 1 23 038 [19], clause 6.2.1 .2.4. (note 4) 


>100H 


Reserved (note 4) 


NOTE 1 : 

NOTE 2: 

NOTE 3: 
NOTE 4: 


Support of this variant is mandatory; it indicates that the FP supports both the default alphabet table (see 

TS 123 038 [19], clause 6.2.1) and the default alphabet extension table (Ibid., clause 6.2.1.1). 

The value indicates that the FP supports both the alphabet table and the alphabet extension table defined in 

TS 1 23 038 [1 9] for this language. 

Bit 8 is 1 indicating that a single octet is used for coding the supported language. 

Values over 7FH are coded with more than one octet, using DECT extension mechanism. For instance value 

BOH is coded with two octets as 0180H. 



'Allowed encoding variant' for encoding TS 123 038 / GSM 8 bit. 

No encoding variant is currently defined. Corresponding subfield(s) are absent. 
'Allowed encoding variant' for encoding TS 123 038 / UCS-2, big-endian. 
No encoding variant is currently defined. Corresponding subfield(s) are absent. 
'Allowed encoding variant' for encoding UTF-8. 

No encoding variant is currently defined. Corresponding subfield(s) are absent. 

7.4.35.5 SMS related entry fields and lists 
7.4.35.5.1 SMS related entry fields 

7.4.35.5.1 .1 Field 'Network side SMS encoding' 

The PP shall use this field to inform the FP of the character encoding and encoding variant that shall be used for a given 
outgoing SMS when sent to the network (see clause 7.4.35.3, section 'PP control over outgoing SMS encoding on 
network side' for more information). 

This field shall be coded as in table 75-27. 

Table 75-27: 'Network side SIVIS encoding' field 



Bit: 



8 



1 



Field identifier = Network side SMS encoding 


0/1 


Length (L) 


0/1 


Editable 


X 


X 


X 


X 


X 


PIN 

protected 


0/1 


Used network side SMS character encoding value 


0/1 


Used encoding variant 1 


0/1 


Used encoding variant 2 



I Octet: 

1 
2 
3 

4 
5 
6 
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Octets 4, 5 and 6 shall always be present. In order to leave control over the used encoding and encoding variants (if any) 
to the FP, the PP shall use the value 'Unknown' (0) in all three octets (4, 5 and 6). 

'Used network side SMS character encoding value' octet (octet 4). The 'SMS character encoding' value indicates to 
the FP the encoding that shall be used for the outgoing SMS. 

Bits 7 6 5 4 3 21 Meaning 

Unknown (see note 1) 

000 00 1 TS 123 038 /GSM 7 bit 

00000 10 TS 123 038 /GSM 8 bit 

11 TS 123 038 / UCS-2, big-endian 

10 UTF-8 

NOTE 1 : This value is used for leaving to the FP control over the used encoding. 

'Used encoding variant 1 and 2' (octets 5 and 6). These subfields indicate to the FP the encoding variant that shall be 
used together with the 'Used SMS character encoding' for the outgoing SMS. See table 75-28 below. 

NOTE 2: For convenient handling of the GSM 7 bit encoding variants, the encoding variant is divided into two 
subfields. 



Table 75-28: Coding of 'Used encoding variant' subfields 



Used encoding 
variant 1 



Comment 



Used encoding 
variant 2 



Comment 



For encoding 'Unknown' 



I Unknown (see note 1) 



I Unknown (see note 1) 



For encoding 'TS 123 038 / GSM 7 bit' (notes 2, 3) 




1..127 



- GSM-7bit default alphabet table 

- National language identifier used for 
locking shift mechanism 




1..127 



- GSI\/l-7bit default alphabet 
extension table 

- National language identifier used 
for single shift mechanism 



Other values 



Reserved 



Other values Reserved 



For encoding 'TS 123 038 / GSM 8 bit' 



Reserved 



Reserved 



For encoding 'TS 123 038 / UCS-2' 



Reserved 



Reserved 



For encoding 'UTF-8' 



Reserved 



Reserved 



NOTE 1 : This value is only used if the 'SIVIS character encoding value' is also 'Unknown' (i.e. the PP shall either 

entirely specify the network side SMS encoding, or not at all). 
NOTE 2: The locking shift mechanism uses the indicated language specific alphabet table instead of the GSM 7 bit 

default alphabet table. The single shift mechanism uses the indicated language specific extension table 

instead of the GSM 7 bit default alphabet extension table. Each mechanism may be used or not, 

independently of the other, with the same or possibly a different language. 
NOTE 3: The present document does not allow the PP to specify a different encoding for each short message used 

on the network side if more than one are needed for the same long SMS (as would be in principle allowed 
by TS 123 038 [19]). For national language identifier values, see clause 7.4.35.4.2.8. 



7.4.35.5.1.2 Field 'SMS size' 

The 'SMS size' field describes the SMS size in bytes. 

The field shall be coded as in table 75-29. 

Table 75-29: 'SMS size' field 
Bits 



8 


7 1 


6 1 5 1 4 1 3 


2 


1 


Field identifier = SMS size 


0/1 


Length (L) 


0/1 


Editable! 


X X X X 


X 


X 


0/1 


Size value 



Octet 
1 
2 
3 
4 
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'Size value' octet (octet 4). The 'Size value' octet(s) contains the whole SMS content size in bytes. 

7.4.35.5.1.3 Field 'SMS content' 

The list entry shall contain the whole SMS content as shown in table 75-30. 

Table 75-30: 'SMS content' field 



Bits 



8 


7 1 


6 1 5 1 4 1 3 1 


2 


1 


Field identifier = SMS content 


0/1 


Length (L) 


0/1 


Editable 1 


X X X X 


X 


X 


SIVIS content 1^' character byte 


... 


SMS content last character byte 



Octet 
1 
2 
3 
4 



For octet 3, each bit indicates whether a property of the field is given (1) or not (0). In the case of 'x', the value is 
reserved for future use. 

Content encoding. The SMS content characters be encoded as follows: 

for an incoming SMS, always in UTF-8 (as specified in clause 7.4.35.2); 

for an outgoing SMS, as specified in the 'Local outgoing SMS content encoding' section of clause 7.4.35.3. 

7.4.35.5.1 .4 Field 'Read status' 

The FP shall set the 'read status' field to 'unread' at entry creation. 

The 'read status' field shall be set to 'read' (or 'unread' again) according to the 'mark entries request' field value used by 
the PP in the 'Read entries' (or 'Search entries') command (see also 'Read status' and 'Reading a partially received SMS' 
in clause 7.4.35.1 for more information). 

The 'Read status' field format is indicated in clause 7.4.10.5.1.5. 

7.4.35.5.1 .5 Field 'Sending request' 

This field is used in the 'Draft SMS List' only, and allows the PP to request sending of the SMS. See table 75-31. 

Table 75-31 : 'Sending request' field 



Bits 



8 


7 1 6 1 5 1 4 1 3 1 


2 


1 1 


Field identifier = Sending request 


0/1 


Length (L) | 


0/1 


editable 1 send | x | x | x | 


X 


X 



Octet 
1 
2 
3 



For octet 3, each bit indicates whether a property of the field is given (1) or not (0). In the case of 'x', the value is 
reserved for future use. 

Bit 6 of octet 3 ('send' bit) may take the value 'send' (1), or 'do not send' (0). The PP sets the bit to 'send' in order to 
request sending of the SMS (following the user request from MMI). After receiving such a request, the FP shall 
immediately remove the corresponding entry from the 'Draft SMS List' and add a new entry in the 'Outgoing SMS List' 
with the same contents. 

7.4.35.5.1.6 Field 'Date and Time' 

The field format shall be that of clause 7.4.10.5.1.4 in TS 102 527-3 [18] ('Field 'Date and Time'). 

For the 'Draft SMS' list, the FP shall use as 'Date and Time' field value of a given entry the date and time of the 
last 'save entry confirm' command relating to that entry. 

For other outgoing SMS relating lists, the 'Date and Time' field value shall be the date/time value of the time 
when the SMS entered the 'Outgoing SMS List'. 
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For the Incoming SMS List, the 'Date and Time' field value shall correspond to the SMS arrival date/time. If 
an SMS arrives in several parts, the 'Date and Time' field shall be updated each time a new part arrives. 

7.4.35.5.2 Incoming SMS List entry fields 

This list contains all the incoming SMS messages stored on any SMS service of the DECT system. See table 75-32. 

Table 75-32: "Incoming SMS List" entry fields 



Field 
identifier 


Field 


Length 
constraint 


Normative action/comment 


Clause 


01H 


Number 


> 1 


Number of the sender 


7.4.10.5.1.2 


02H 


Name 


>1 


Name of tlie sender 


7.4.10.5.1.3 


03H 


Date and Time 


>5 


Date and Time of tlie message arrival 


7.4.10.5.1.4 


04H 


Read status 


= 1 


Indicates whether entry is shown first 
time 


7.4.10.5.1.5 and 
7.4.35.5.1.4 


05H 


SMS service id 


>2 


Identifier of the SIVIS service on which 
the message was received 


7.4.35.4.2.1 


06H 


SIVIS size 


>2 


Size of the whole SMS content in 
bytes. Useful for PPs not reading the 
whole SMS in one read command 


7.4.35.5.1.2 


07H 


SIVIS content 


> 1 


Whole SMS text content 


7.4.35.5.1.2 



7.4.35.5.3 Sent SMS List entry fields 

This list contains all the sent SMS messages stored on any SMS service of the DECT system. See table 75-33. 

Table 75-33: "Sent SMS List" entry fields 



Field 
identifier 


Field 


Length 
constraint 


Normative action/comment 


Clause 


01H 


Number 


>1 


Number of the receiver 


7.4.10.5.1.2 


02H 


Name 


>1 


Name of the receiver 


7.4.10.5.1.3 


03H 


Date and Time 


>5 


Date and Time of the message sent 


7.4.10.5.1.4 


04H 


SMS service id 


>2 


Identifier of the SMS service on which 
the message was sent 


7.4.35.4.2.1 


05H 


Network side 
SMS encoding 


>3 


Encoding chosen by the PP for the 
outgoing SMS on network side 


7.4.35.5.1.1 


06H 


SMS size 


>2 


Size of the whole SMS content in 
bytes. Useful for PPs not reading the 
whole SMS in one read command 


7.4.35.5.1.2 


07H 


SMS content 


>1 


Whole SMS text content 


7.4.35.5.1.3 
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7.4.35.5.4 Outgoing SMS List entry fields 

This list contains all the outgoing SMS messages stored on any SMS service of the DECT system. See table 75-34. 

Table 75-34: "Outgoing SMS List" entry fields 



Field 
identifier 


Field 


Length 
constraint 


Normative action/comment 


Clause 


01H 


Number 


> 1 


Number of the receiver 


7.4.10.5.1.2 


02H 


Name 


> 1 


Name of the receiver 


7.4.10.5.1.3 


03H 


Date and Time 


>5 


Date and Time of the message sent 


7.4.10.5.1.4 


04H 


SMS service id 


>2 


Identifier of the SIVIS service on which 
the message is to be sent 


7.4.35.4.2.1 


05H 


Networl< side 
SIVIS encoding 


>3 


Encoding chosen by the PP for the 
outgoing SIVIS on network side 


7.4.35.5.1.1 


06H 


SIVIS size 


>2 


Size of the whole SMS content. Useful 
for PPs not reading the whole SMS in 
one read command 


7.4.35.5.1.2 


07H 


SIVIS content 


>2 


Whole SMS text content 


7.4.35.5.1.3 



7.4.35.5.5 Draft SMS List entry fields 

This list contains all the draft SMS messages stored on any SMS service of the DECT system. See table 75-35. 

Table 75-35: "Draft SMS List" entry fields 



Field 
identifier 


Field 


Length 
constraint 


Normative action/comment 


Clause 


01H 


Number 


>1 


Number of the receiver 


7.4.10.5.1.2 


02H 


Name 


>1 


Name of the receiver 


7.4.10.5.1.3 


03H 


Date and Time 


>5 


Date and Time when the message 
was last saved 


7.4.10.5.1.4 


04H 


SMS service id 


>2 


Identifier of the SMS service on which 
the message is to be sent 


7.4.35.4.2.1 


05H 


Sending request 


= 1 


set to 1 to indicate intention of the PP 
user to send the message 


7.4.35.5.1.5 


06H 


Network side 
SMS encoding 


>3 


Encoding chosen by the PP for the 
outgoing SMS on network side 


7.4.35.5.1.1 


07H 


SMS size 


>2 


Size of the whole SMS content. Useful 
for PPs not reading the whole SMS in 
one read command 


7.4.35.5.1.2 


08H 


SMS content 


>2 


Whole SMS text content 


7.4.35.5.1.3 



7.4.36 (Digital) Telepinone Answering Macliine (DTAM) 
7.4.36.1 DTAM description 



7.4.36.1.1 



General requirements 



The purpose of the DTAM feature is to allow the PP user to control a local or remote DTAM and to manage the 
recorded messages. 

DTAM (Digital Telephone Answering Machine). Entity answering incoming calls if not answered by the user within 
a configured timeout. 

If a line has an associated DTAM (i.e. the DTAM 'handles' the line), and an external incoming call on that line is 
received but not answered by the local user within DTAM timeout, the DTAM (if activated) picks up the call and plays 
a pre-recorded welcome message inviting the remote user to leave a message in that DTAM instead. 
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A DTAM holds two ordered series of messages: the welcome messages (possibly only 1), described in clause 7.4.36.1.4 
and the DTAM incoming messages, described in clause 7.4.36.1.3. The DTAM allows the local user to manage both 
series. 

Local or remote DTAM. A DTAM may be either located on the FP (local DTAM) or in the network (remote DTAM), 
e.g. located either in a PSTN or VoIP network. Whether local or remote, the DTAM role is to answer calls presented to 
the local system after DTAM timeout. 

Voice-oriented DTAM. A local or remote DTAM that does NOT allow random access to DTAM incoming messages. 
Voice oriented DTAMs are handled in clause 7.4.36.2.1. 

Visual DTAM. A local or remote DTAM that allows random access to DTAM incoming messages. Visual DTAMs are 
handled in clause 7.4.36.2.2. 

DTAM number. Some remote DTAMs need to be called through a DTAM number (e.g. Voice oriented DTAMs) when 
a 'DTAM consulting call' (see clauses 7.4.36.1.3 and 7.4.36.3) is placed. 

When required, the DTAM number is either provided by the PP as keypad information (e.g. dialled by the user) or 
provided in the 'DTAM number' field of the DTAM Settings List. See clause 7.4.36.5.1.2 for more information. 

NOTE 1 : If the PP does not provide any keypad information, the «MULTIKEYPAD» IE is still sent but remains 
empty. 

NOTE 2: In the case of double specification (i.e. as keypad information and DTAM setting), the FP may either 
override the setting with the received keypad information, or ignore the keypad information. 

NOTE 3: In all cases the FP identifies the concerned DTAM through the 'line id' provided by the PP in the same 
{CC-INFO} message. 

DTAM multiplicity. The DTAM feature allows the control of a maximum of 64 local or remote DTAMs associated 
with the DECT system (see clause 7.4.36.5.1.1). 

Screening. Ability for the local user to listen to a message while it is being recorded by the remote user and to possibly 
pick up the call (and talk with the remote user) before recording has ended. Screening is only possible with a local 
DTAM. 

7.4.36.1 .2 DTAM settings management 

Line-DTAM association. One DTAM at most may be associated with a given line. Conversely, several lines may be 
associated with the same DTAM. 

DTAM settings. DTAM settings are described in the DTAM Settings List (see clause 7.4.36.5.2). This list contains one 
entry per line-DTAM association, so that line-specific settings may be defined. 

If a DTAM does not allow the definition of line-specific values for a given setting, the FP shall ensure that the setting 
value is the same for every entry describing an association of this DTAM with a line. 

EXAMPLE: If a PP modifies a non-line specific setting for line 0, whereas the DTAM handles lines and 1, 
the FP shall copy the setting value in the entry for line 1 . 

NOTE: Some fields contain several settings, that could be not all line-specific, or not all non-line specific. 

Default entry for a non-associated DTAM. A temporarily not (or not yet) associated DTAM shall be represented in 
the DTAM Settings List with a default entry, with the line id field set to 'None' (value 127). As a result, the following 
applies: 

For creating an association with a DTAM: 

If this is the DTAM first association, no new entry in the DTAM Settings List shall be created, but the default 
entry shall be used, with the 'None' value for the line id replaced with the associated line id. 

If this is not the DTAM first association, a new entry in the list shall be created, with that DTAM id and the 
associated line id. 

Voice-oriented DTAMs associations with lines are also subject to restrictions with regard to PP attachments to lines for 
preserving message confidentiality (see clause 7.4.36.2.1). These restrictions do not apply for Visual DTAMs. 
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For deleting an association wih a DTAM: 



If this is the DTAM last association, the Hne id of that association shall be replaced with the 'None' value, thus 
recreating the default entry of the DTAM. 

If this is not the DTAM last association, the entry of that association shall be removed from the list. 

7.4.36.1 .3 DTAM incoming and welcome messages management 

DTAM incoming message. A DTAM incoming message is a message present in the DTAM following an external 
incoming call. It may be: 

a message left by the remote user if the DTAM answered the incoming call after DTAM timeout; 

(for DTAMs managing missed calls) an artificial message created by the DTAM to report a missed call. 

NOTE: When a DTAM is activated on a line, a missed call occurs if the remote user hangs up before DTAM 
timeout. Some (especially remote) DTAMs also manage missed calls. 

DTAM incoming call. A DTAM incoming call is an incoming external call for which a DTAM message exists in the 
DTAM (i.e. either a DTAM answered call, or a missed call if managed). 

DTAM Incoming Calls List. The list accessible with the List Access feature, containing an entry for each DTAM call. 
Visual DTAMs use this list as a base for displaying the list of calls to the user for message listening and management. 

Welcome messages. A DTAM may manage one or several welcome messages. The DTAM Welcome Message List 
shall contain one entry per available position in the DTAM for recording a welcome message. 

The number of positions (number of entries in the list with corresponding DTAM id) shall always correspond to the 
maximum number of welcome messages supported by the DTAM and should remain stable over time. If a position is 
not used (empty message), the message time duration field of the corresponding list entry shall be zero. 

The PP user shall use the DTAM Settings List ('Welcome message parameters' field) in order to select the welcome 
message to be used for a given line. The PP user may use the same welcome message for several lines. The FP shall 
ensure that the selected welcome message is owned by the DTAM handling the line (via the 'DTAM full identifier' field 
of the 'DTAM Welcome Message List'). 

If several welcome messages are recorded for a DTAM, the one used by the DTAM when answering an incoming call: 

could be selected by the user depending on the time of the day, etc.; 

and could also be configured to depend on the line of the answered external incoming call if the DTAM 
supports it. 

DTAM consulting call. A DTAM consulting call is an outgoing call performed by the local user in order to: 

listen to and manage DTAM incoming messages; 

create and manage DTAM welcome messages. 

These operations are performed though the use of DTAM commands (as a complete exchange) sent within a DTAM 
session. See clause 7.4.36.3 for more information. 

DTAM status information. DTAM status information is also sent from FP to PP for some of these DTAM commands 
(as a complete exchange), in the form of a 'DTAM status command' (as a message). The DTAM status information is 
sent some time after the command confirmation to indicate the completion status of this command. 

A DTAM command is sent asynchronously with respect to PP sending of subsequent commands. For example, the PP 
might have already issued a new command when the DTAM status information for the previous command arrives. 

See clause 7.4.36.4.13 for more information about the DTAM status information. 
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Message index used in DTAM commands. Some DTAM commands use a message index. DTAM incoming messages 
and welcome messages use different kinds of indices: 

For welcome messages, a position index is used, as described in clause 7.4.36.5.4. This position index is a 
specific field of the 'DTAM welcome messages list' that represents an available position in the DTAM and is 
stable over time. 

For DTAM incoming messages, the corresponding entry index in the DTAM incoming messages list is used. 

7.4.36.2 DTAM profiles 

There are two types of DTAMs, that differ in the way they reference DTAM incoming calls, and in their use (or not) of 
the DTAM Incoming Calls List. 

NOTE: A DTAM allowing both approaches can be considered as two separate DTAMs in the DECT system. 
See annex G for some DTAM service use case examples. 

7.4.36.2.1 Voice oriented DTAM 

Voice-oriented DTAMs use the notion of current DTAM incoming message and do NOT make use of the DTAM 
Incoming Calls List. 

NOTE 1 : Use of the 'Voice oriented' DTAM profile is only beneficial if the DTAM provides feedback when 
DTAM commands are forwarded to it. 

EXAMPLE 1 : Voice-oriented local DTAMs should always provide feedback for DTAM commands and therefore 
benefit from the present profile. 

EXAMPLE 2: Some existing voice oriented remote DTAMs (e.g. based on DTMF signalling) only provide 
voice-based feedback and therefore will not find a real benefit in the present profile. 

A FP shall indicate that a DTAM is Voice oriented by use of the 'Voice/visual' property of the DTAM full identifier of 
the DTAM Settings List (see clause 7.4.36.5. LI). 

By definition, a voice oriented DTAM shall handle a single stream of messages for all lines associated with it. 

EXAMPLE 3: A voice oriented DTAMs that would be able to handle separate streams of messages for different 
lines shall use one DTAM id per stream. 

Line-DTAM association restrictions. For a voice-oriented DTAM, and in order to preserve message confidentiality, a 
PP shall either be attached to all lines handled by that DTAM (i.e the PP has access to the DTAM), or to none of them 
(i.e. the PP has no access to the DTAM). This implies that the following rules shall be respected: 

If case of new attachment: all lines handled by a voice-oriented DTAM shall be attached together to the PP, or 
none of them. 

In the case of detachment: all lines handled by a voice-oriented DTAM shall be detached together from the PP, 
or none of them. 

In the case of new association of a line with a voice-oriented DTAM: all PPs having access to the DTAM shall 
also be newly attached to the line (if not already attached to it). 

In the case of de-association: there is no restriction. A line not handled by a voice-oriented DTAM may be 
freely attached/detached to/from any PP. 

Message playing. The user of a voice-oriented DTAM does not explicitly request the playing of a DTAM incoming 
message (i.e. it is the DTAM itself that starts the playing of such a message when it becomes current). Therefore the 
'Play message' command with play mode=0 is not used for the management of DTAM incoming messages (see 
table 75-36 below). 

NOTE 2: However the user may explicitly request which message becomes current by using the 'Select neighbour 
message' command. 
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Current message for a voice oriented DTAM. When a DTAM session is open with a voice-oriented DTAM, a current 
message is defined at DTAM level for most of the session duration. 

NOTE 3: At DTAM session start, the current message should be the first message in the DTAM stream of 
messages. 

NOTE 4: When a message is being played, the current message is the message being played. When no message is 
played, current message definition depends on the voice oriented DTAM implementation. 

Current message change. A voice oriented DTAM changes the current message by itself, i.e. with no user or DECT 
system intervention, when the current message processing ends and the next message becomes the new current 

message. 

The user may also change the current message: 

by using the 'Select neighbour message' command. In that case, the message placed after or before the current 
message becomes the new current message; 

by using the 'Delete message' command. In that case, the next message in the list of DTAM incoming 
messages should become the new current message. 

DTAM commands for DTAM incoming messages. When a DTAM incoming current message is defined in a voice- 
oriented DTAM, the user is able to send successful commands to the FP (see clause 7.4.36.4). In other words, for the 
management of DTAM incoming messages: 

all commands shall refer to the current message; 

the current message based variant of the 'Delete message' command, (i.e. with message index '0' indicating 
'current message') shall always be used. 

NOTE 5: Such restrictions do not apply to the management of welcome messages (see clause 7.4.36.1.3). 

Paused message playing. When a message playing is paused, the paused message is still considered as being played 
and therefore continues to be the current message. In particular, the 'Stop playing message' command may apply to 
paused messages. 

Table 75-36: DTAM commands statuses for Voice oriented DTAIVIs 



Command 
nb 


Command name 


Applies to 


FP 
Status 
(notel) 


Comment 


Current 
message 


Indicated 
index 


OOH 


Start DTAM session 


- 


- 


M 


Common to all DTAMs 


01H 


Start DTAM session confirm 


- 


- 


M 




40H 


Negative acl<nowledgement 


- 


- 


M 


FP answer when there is an error 


41 H 


DTAM status 


- 


- 


M 


Asynchronous status information from 
FP 


04H 


Select neighbour message 


YES 


- 


1 
M 


Select next or previous message 

- for the management of Welcome 
messages 

- for the management of DTAM 
incoming messages 


05H 


Select neighbour message confirm 


- 


- 


M 




08H 


Play message 


- 


YES 


M 

1 


if play mode=0 ('play indicated 
message') 

- for the management of Welcome 
messages 

- for the management of DTAM 
incoming messages 


YES 
YES 


- 


M 
M 


If play mode=1 ('restart/rewind 
playing of currently played message') 

- for local DTAMs (Welcome and 
DTAM incoming messages) 

- for remote DTAMs (Welcome and 
DTAM incoming messages) 
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Command 
nb 


Command name 


Applies to 


FP 
Status 
(notel) 


Comment 


Current 
message 


Indicated 
index 


09H 


Play message confirm 


- 


- 


M 




OAH 


Delete message 


YES 


- 


M 


- for deleting DTAM incoming 
messages 


- 


YES 


M 


- for deleting welcome messages 


OBH 


Delete message confirm 


- 


- 


M 




OCH 


Pause/resume playing of message 


YES 


- 


M 




ODH 


Pause/resume playing of message 
confirm 


- 


- 


M 




10H 


Stop playing message 


YES 


- 


M 




11H 


Stop playing message confirm 


- 


- 


M 




12H 


Record welcome message 


- 


YES 


M 


Specific to welcome message 
management (note 2) 


13H 


Record welcome message confirm 


- 


- 


M 




14H 


Stop recording welcome message 


YES 


- 


M 


Specific to welcome message 
management (note 2) 


15H 


Stop recording welcome message 
confirm 


- 


- 


M 




>80H 


Reserved for proprietary DTAIVI 

commands 

all other values reserved 










NOTE 1 : For remote voice oriented DTAMs, a mandatory status only applies if the underlying remote DTAM supports the 

command. Otherwise, the FP shall work in best effort mode. 
NOTE 2: Record welcome message command is always index based (i.e. even for voice oriented DTAMs), while Stop 

recording weicome message' is not (stops current recording). 



7.4.36.2.2 



Visual DTAM 



Visual DTAMs display message lists to the user and manage messages with DTAM commands using an explicit 
message index for referring to messages. 

A FP shall indicate that a DTAM is a Visual DTAM by use of the 'Voice/visual' property of the DTAM full identifier of 
the DTAM Settings List (see clause 7.4.36.5.1.1). 

Message management through DTAM commands. For managing a visual DTAM, the PP shall setup a DTAM 
consulting call, open a DTAM session within that call and issue DTAM commands within that session, as described in 
clause 7.4.36.3. 

Use of call/message lists. Within the DTAM consulting call, one of more LiA sessions in parallel to the DTAM session 
shall be opened with the DTAM Incoming Calls List and/or the Welcome messages list. 

These lists are retrieved so that the corresponding lists of messages may be presented to the user, and in order to get 
access to the message indices to be used within some DTAM commands (see below 'Commands using a message 
index'). 

Current message for a visual DTAM. For visual DTAMs, the notion of current message is limited to time intervals 
where a message is played (or for which message playing is paused). 

NOTE: This is in contrast to the case of a Voice oriented DTAM where a current message is defined at DTAM 
level for most of the session duration. 

Commands applying to current message. When a current message is defined, the user is able to send commands 
applying to the current message (for the list of such commands, see clause 7.4.36.4.1, table 75-37). 

If no current message is defined at the time when the command is received, the FP shall return a negative 
acknowledgement (the negative acknowledgement error value depends on the command). 

Commands using a message index. Commands not applying to the current message shall specify the targeted message 
through a message index. The used message index depends on the type of message (DTAM incoming or Welcome) and 



£75/ 



129 



ETSI TS 102 527-5 VI. 1.1 (2013-04) 



is described in clause 7.4.36.1.3 ('Message index used in DTAM commands' subsection). In both cases, an LiA session 
with the corresponding list is needed, but the index definition varies. 

Delete message command. The 'Delete message' command has two variants. For a Visual DTAM, it shall always use a 
message index based variant, as indicated in the following table 75-37 (the current message based variant of the 
command is reserved for voice oriented DTAMs). 

Within a DTAM consulting call, the 'Delete entry' LiA command and the 'Delete message' DTAM command shall have 
the same result on both the 'DTAM incoming call' list and the DTAM itself. 

EXAMPLE: This implies that the PP, when using the 'Delete message' DTAM command, shall update the result 
of any previously used 'Read entries' command, as if a 'Delete entry' command had been used. 

Table 75-37: DTAM commands statuses for Visual DTAMs 



Command 
nb 


Command name 


Applies to 


FP 
Status 
(notel) 


Comment 


Current 
message 


Indicated 
index 


OOH 


Start DTAM session 


- 


- 


M 


Common to all DTAMs 


01H 


Start DTAM session confirm 


- 


- 


M 




40H 


Negative acknowledgement 


- 


- 


M 


FP answer when there is an error 


41H 


DTAM status 


- 


- 


M 


Asynchronous status information from FP 


04H 


Select neighbour message 


- 


- 


1 


Select next or previous message 


05H 


Select neighbour message confirm 


- 


- 


1 




08H 


Play message 


- 


YES 


M 


if play mode=0 ('play indicated 
message') 


YES 


- 


M 


If play mode=1 ('restart/rewind playing of 
currently played message') 


09H 


Play message confirm 


- 


- 


M 




OAH 


Delete message 


- 


YES 
YES 


M 
M 


- for DTAM incoming messages 

- for Welcome messages 


OBH 


Delete message confirm 


- 


- 


M 




OCH 


Pause/resume playing of message 


YES 


- 


M 




ODH 


Pause/resume playing of message 
confirm 


- 


- 


M 




10H 


Stop playing message 


YES 


- 


M 




11H 


Stop playing message confirm 


- 


- 


M 




12H 


Record welcome message 


- 


YES 


M 


Specific to welcome message 
management (note 2) 


13H 


Record welcome message confirm 


- 


- 


M 




14H 


Stop recording welcome message 


YES 


- 


M 


Specific to welcome message 
management (note 2) 


15H 


Stop recording welcome message 
confirm 


- 


- 


M 




>80H 


Reserved for proprietary DTAM 

commands 

all other values reserved 










NOTE 1 : For remote visual DTAMs, a mandatory status only applies if the underlying remote DTAM supports the 

command. Otherwise, the FP shall work in best effort mode. For example, if a remote visual DTAM offers a 
message downloading interface, commands only requiring a local message file management on FP side shall 
be implemented (i.e. 08H in modes and 1, OCH, 10H); if a remote visual DTAM offers a message uploading 
interface, commands only requiring a local message file creation on FP side shall be implemented (i.e. 12H 
and 14H). 

NOTE 2: Record welcome message command is index based, while Stop recording welcome message' is not (stops 
current recording). 



7.4.36.3 DTAM consulting call 



7.4.36.3.1 



General description 



A DTAM consulting call allows the user to open a session with the DTAM (called a DTAM session) in order to control 
the messages (i.e. DTAM incoming messages and welcome messages) through the use of commands, and to listen to 
these messages. 
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DTAM session multiplicity. 

FP requirements: 

The FP shall not allow two simultaneous DTAM sessions with the same DTAM in the DECT system (whether 
from the same or different PPs): 

If a DTAM session is already open with a DTAM, the FP shall answer any attempt to start a session with 
that DTAM with a negative acknowledgement (reject reason 'DTAM unavailable'). 

The FP may (but is not forced to) allow several simultaneous DTAM sessions (with different DTAMs and 
from different PPs) in the DECT system: 

However, if the FP does not support an additional DTAM session, it shall answer any attempt to start a 
new DTAM session in the DECT system with a negative acknowledgement (reject reason 'not enough 
resources'). 

NOTE 1 : If both reject reasons apply, the FP implementer may use either of them. 

PP requirements: 

A PP shall only start a single DTAM session at the same time (whether with the same or different DTAMs). 

When attempting to start a DTAM session with a 'start DTAM session' command, the PP shall be prepared to 
receive a negative acknowledgement as indicated above. 

When sending a {CC-SETUP} message for establishing a DTAM consulting call, the values used for the «BASIC 
SERVICE» IE shall be as follows. 

<Basic servico field. A DTAM consulting call shall use the 'DTAM wideband speech default setup attributes' value 
for the <basic servico field 

This value indicates that the established call behaves like a regular TS 102 527-3 [18] outgoing voice call as to listening 
of messages, but that a DTAM session will also be started within that call for the sending of controlling commands to 
the DTAM. 

NOTE 2: However, the DTAM feature restricts the commands that may be issued within a DTAM consulting call. 
For example, it is not allowed to initiate an outgoing parallel call when a first DTAM consulting call is 
established. 

Call class field. The used <call class> field value shall depend on the DTAM location as follows: 

• For a local DTAM, the 'Internal call setup' value shall be used. 

• For a remote DTAM, the 'Normal call setup' value shall be used. 
LiA session within DTAM consulting call. 

FP requirements: 

• The FP shall always allow the PP to start at least one list access session (in addition to the DTAM session) 
within the DTAM consulting call as for any voice call (see clause 7.4.10.6.5). 

• The FP shall ensure that any LiA session started with either the 'DTAM Incoming Calls List' or the 'DTAM 
welcome messages list' may result in a DTAM consulting call with the concerned DTAM. In other words: 

If the PP starts the LiA session within an LiA service call, the FP shall check that it has enough resources 
to allow the transformation of that call into a DTAM consulting call (including the new DTAM session), 
as described in clause 7.4.36.5.5. Otherwise, it shall answer with a negative acknowledgement 'not 
enough resources'. 

If the PP starts the LiA session within an existing voice call, the FP shall answer with a negative 
acknowledgement 'list not supported'. 

NOTE 3: Commands (as a message) from LiA session and DTAM session use different protocol discriminators and 
therefore may be easily distinguished. 
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PP requirements: 

• The PP shall start a list access session within the DTAM consulting call in the following cases: 

for visual DTAMs, for the management of DTAM incoming messages; 

for all DTAMs (i.e. whatever the DTAM profile) for the management of Welcome messages. 

NOTE 4: Both lists do not need to be accessed simultaneously. An additional LiA session with the DTAM Settings 
List may be needed for PIN management. 

The PP shall not use an existing voice call in order to start an LiA session with the 'DTAM Incoming Calls 
List' or the 'DTAM welcome messages list', as such a call cannot be transformed into a DTAM consulting call. 

DTAM consulting call release. The procedure for releasing a DTAM consulting call is identical to the release a regular 
voice call, and is performed by sending a {CC-RELEASE} message. The DTAM consulting call release also terminates 
the included DTAM session. See the following figure 80-4 for an example. 
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PP 



FP 



{CC-SETUP} 



« BASIC SERVICE, 

<basic service = 'DTAM wideband speech default setup attributes' 

<call class = 'Normal call setup' > 
» 

{CC-CONNECT} 



« CALL-INFORMATION, call id=3» 



{CC-INFO} 



« CALL-INFORMATION, call id=3, call status = 'CS call setup ack' 



Store call in call table 
and assign call id 



Early CC-CONNECT 
message used: 
CS call connect call status 
not yet reached 



For any DTAM: use of Line id for identifying DTAM (local or remote) + optional DTAM number 

{CC-INFO} 



« MULTI-KEYPAD, < Keypad info = or DTAM number > 

« CALL-INFORMATION, call id=3, line id = one of the DTAM line 



{CC-INFO} 



« CALL-INFORMATION, call id=3, call status = 'CS call proc' » 
{CC-INFO} 



« CALL-INFORMATION, call id=3, call status = 'CS call alerting' >; 
{CC-INFO} 



« CALL-INFORMATION, call id=3, call status = 'CS call connect' > 



{IWU-to-IWU} 



« Start DTAM session <Line id> » 
{IWU-to-IWU} 



: Start DTAM session confirm : 



For a Visual DTAM (if DTAM incoming messages are managed) 

{IWU-to-IWU} 



« Start LiA session <DTAM incoming call list> » 
{IWU-to-IWU} 



« Start LiA session confirm » 
DTAM incoming call list retrieval for messages management 



For any DTAM (Voice oriented or Visual) if welcome messages are managed 

{IWU-to-IWU} 



If remote DTAM: start I 

outgoing call towards r 

DTAM I 



: Start LiA session <DTAM welcome message list> » 
{IWU-to-IWU} 



« Start LiA session confirm » 
DTAM welcome messages list retrieval for 
welcome management 



Included DTAM session 
is started 

For use of DTAM 
commands 



For visual 
management of 
incoming messages 

and retrieval of 
message indices 
used in DTAM 
commands 



For visual 
management of 
welcome messages 

and retrieval of 
message indices 
used in DTAM 
commands 



Figure 80-4: DTAM consulting call of a local or remote DTAM (early CC-CONNECT version} 
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7.4.36.3.2 Parallel call during active DTAM consulting call 

Support of parallel call procedures when a first DTAM consulting call is active is detailed in the following table 75-38. 

Only the support of a regular parallel call is considered in this table. A PP shall not be involved in several DTAM 
consulting calls at the same time whether with the same or different DTAMs. 

Table 75-38: Supported parallel call procedure after first DTAM consulting call 



Procedure name 


PP 
Support 


FP 
Support 


Outgoing parallel call initiation (external or internal) 





M 


Call waiting indication (external or internal) 


M 


M 


Call waiting acceptance 


M 


M 


Call waiting rejection 


M 


M 


Active call release with replacement (from PP to FP) 





M 


Call toggle request (external or internal) 





M 


Negative acknowledgement 


M 


M 


Putting a call on-hold 





M 


Resuming a call put on-hold 





M 


Intrusion call request indication (only internal) 








3-party conference call request (external or internal) 








Call transfer request (external or internal) 








Explicit call intrusion 









7.4.36.4 



DTAM commands 



7.4.36.4.1 



DTAM commands general requirements 



DTAM commands (as a message) are based on a {IWU-INFO} message containing the «IWU to IWU» IE with 
dedicated protocol discriminator '15'H. 

The general structure of a DTAM command (as a message) is indicated in the following table 75-39. 
Table 75-39: Values used within the {IWU-INFO} message 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 


<S/R bit> 


1 


Transmission of message 


<Protocol DiscrimJnator> 


15H 


DTAIVI access 


<Command > 


0.. 127 


DTAM command (see note) 


<Command specific byte 0> 












<Command specific byte L-2> 






NOTE: Values from 128 on are reserved for proprietary list access commands. 



For the purpose of managing DTAM incoming messages and welcome messages within a DTAM consulting call, the 
following list access commands are defined. See table 75-40. 
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Table 75-40: DTAM commands and their direction 



Cmd 
nb 


Command name 


PP ->FP 


FP ->PP 


Applies to 


Current 
message 


Indicated 
index 


OOH 


Start DTAM session 


YES 


- 


- 


- 


01H 


Start DTAM session confirm 


- 


YES 


- 


- 


40H 


Negative acknowledgement 


- 


YES 


- 


- 


41H 


DTAM status 


- 


YES 


- 


- 


04H 


Select neighbour message 


YES 


- 


YES 


- 


05H 


Select neighbour message confirm 


- 


YES 


- 


- 


08H 


Play message 


YES 


- 


YES 
(note 1) 


YES 
(note 2) 


09H 


Play message confirm 


- 


YES 


- 


- 


OAH 


Delete message 


YES 


- 


YES 
(note 3) 


YES 
(note 4) 


OBH 


Delete message confirm 


- 


YES 


- 


- 


OCH 


Pause/resume playing of message 


YES 


- 


YES 


- 


ODH 


Pause/resume playing of message confirm 


- 


YES 


- 


- 


10H 


Stop playing message 


YES 


- 


YES 


- 


11H 


Stop playing message confirm 


- 


YES 


- 


- 


12H 


Record welcome message 


YES 


- 


- 


YES 


13H 


Record welcome message confirm 


- 


YES 


- 


- 


14H 


Stop recording welcome message 


YES 


- 


YES 


- 


15H 


Stop recording welcome message confirm 


- 


YES 


- 


- 


>80H 


Reserved for proprietary DTAM commands 
all other values reserved 










NOTE 1 : For play mode = 1 (i.e. 'restart/rewind playing of currently played message') only. 
NOTE 2: For play mode = (i.e. 'play indicated message') only. 
NOTE 3: For a voice oriented DTAM and if message type is DTAIVI incoming message. 
NOTE 4: For a visual DTAIVI or if message type is Welcome message. 



7.4.36.4.2 



Start DTAM session 



7.4.36.4.2.1 Start DTAM session command 

See table 75-41 below. 

Table 75-41 : Values used within {IWU-INFO} message to request the starting of a DTAIVI session 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 




<Protocol Discriminator> 


15H 


DTAM 




<Command = Start DTAM 
session > 


OOH 


DTAM command 




<DTAM id> 


0..63 


DTAM id 



7.4.36.4.2.2 Start DTAM session confirm command 

See table 75-42 below. 
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Table 75-42: Values used within {IWU-INFO} message to confirm or 
reject the starting of a DTAIVI session 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 




<Protocol Discriminator> 


15H 


DTAM 




<Command = Start DTAIVI 
session confirm > 


01H 


DTAM command 




<DTAM id> 


0..63 


DTAM id 




<DTAIVI session identifier> 


0..127 


Session identifier (see note 1) 




<Discriminator typo 


OOH, 01H 


Undefined, EMC (see note 2) 




<Discriminator> 


OOH..FFH 


EMC value high byte 




<Discriminator> 


OOH..FFH 


EMC value low byte 




<DTAM start session reject 
reason> 


O..FFH 


Reject reason in the case of reject 


NOTE 1 : This field can be extended for values up to 16 383. See note 1 at table 39. 

NOTE 2: Discriminator type set to '1' (= ElVIC) indicates the support of proprietary DTAM commands. For 

distinguishing proprietary elements from different manufacturers, the ElVIC is given in the following two 
octets. If the discriminator type is set to '0', the following two octets are do not care. The PP shall not use 
proprietary elements if either the Discriminator type is '0' (= Undefined) or the ElVIC is different from the 
own one. Proprietary elements shall have identifiers with the most significant bit set to '1'. 



Possible error cases: 

If start session is rejected, the session identifier shall be set to 0, and the field reject reason shall indicate the appropriate 
reason. 

DTAM start session reject reason: 

Bits 87654321 Meaning 

00000000 not enough resources 

1 unknown DTAM id 

10 DTAM unavailab le 

0000001 1 maximum number of DTAM sessions supported by the FP reached 
10 PIN code required 

all other values reserved 



7.4.36.4.3 



Select neighbour message 



7.4.36.4.3.1 



'Select neighbour message' command 



This command allows the PP to select the next (or previous) message in the list of DTAM incoming messages. If 
successful, the newly selected message becomes the new 'current message' in the DTAM. 

EXAMPLE 1 ; A voice oriented DTAM may require an explicit request from the user for processing the previous 
or next message. In that case, use of the command is essential for consulting all messages. 

EXAMPLE 2: Some voice oriented DTAMs could process messages one after the other without any user 

intervention. However, even in this case the command could be used to request an anticipated 
processing of the next message, or the processing of the previous message instead of the next one. 

NOTE: This command cannot be used for managing welcome messages. 

See table 75-43 below. 
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Table 75-43: Values used within {IWU-INFO} message for the "Select neighbour message" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 




<Protocol Discriminator> 


15H 


DTAM 




<Command = Select neighbour 
message> 


04H 


DTAM command 




<DTAM session identifier> 


0..127 


Session identifier (see note) 




<select previous/next> 



1 


- select previous message 

- select next message 


NOTE: 'DTAM session identifier' can be extended for values up to 16 383. See note 1 at table 39. 



Possible error cases: 

The FP shall answer the 'Select neighbour message' command with a negative acknowledgement (see 
clause 7.4.36.4.10) with one of the following reject reasons, in the indicated cases: 

Message list empty, if the DTAM incoming message list is empty. 

No current message defined, if no current message was defined at command reception time. 

Beginning of message list reached, if the current message is the first message of the list, and the previous 
message is selected, but the DTAM does not automatically select the last message of the list as a result. 

End of message list reached, if the current message is the last message of the list, and the next message is 
selected, but the DTAM does not automatically select the first message of the list as a result. 

Command not implemented, if the DTAM is a Visual DTAM which does not implement the command. 

7.4.36.4.3.2 'Select neighbour message confirm' command 

This command from FP confirms the next or previous DTAM incoming message selection. See table 75-44 below. 

Table 75-44: Values used within {IWU-INFO} message 
for the "Select neighbour message confirm" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 




<Protocol Discriminator> 


15H 


DTAM 




<Command = Select neighbour 
message confirm> 


05H 


DTAM command 




<DTAM session identifier> 


0..127 


Session identifier (see note) 


NOTE: 'DTAM session identifier' can be extended for values up to 16 383. See note 1 at table 39. 



7.4.36.4.4 



Play message 



7.4.36.4.4.1 'Play message' command 

The 'Play message' command allows the PP: 

If play mode = 0, to request the playing of the indicated DTAM incoming message or welcome message. In 
that case the command shall always be index based. 

NOTE 1: Voice oriented DTAMs (for which no index is available) do not use the 'Play message' command, except 
for replaying a message (see below). 
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If play mode=l, to request that the current playing of a message (DTAM incoming or welcome) be either 
restarted at the beginning, or 'rewinded' for the indicated number of seconds. 

NOTE 2: A paused message may also be resumed with play mode=l, if resuming is desired at a playtime position 
different from the current one. 

See table 75-45 below. 

Table 75-45: Values used within {IWU-INFO} message for the "Play message" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 




<Protocol Discriminator> 


15H 


DTAM 




<Command = Play message> 


08H 


DTAM command 




<DTAM session identifier> 


0..127 


Session identifier (see note 1) 




<Messages typo 



1 


DTAM incoming messages 
Welcome messages 




<Message index> 





{for play mode = 1 only) current 
message is targeted 


1..127 


{for play mode = only) Index of the 
message to be played 
(see notes 1 ,2 and 3) 




<Play mode> 




1 


- play indicated message 

- restart/rewind playing of currently 
played message (note 4) 




<Number of seconds> 





{for play mode = only) 
Reserved (note 5) 





{for play mode = 1 only) 

Restart playing from the beginning 


1..255 


{for play mode = 1 only) 
Rewind playing this number of 
seconds from current playtime 


NOTE 1 : This field can be extended for values up to 16 383. See note 1 at table 39. 

NOTE 2: When play mode=0, the command is always index based and cannot be used with Message index va\ue 
'0' (indicating use of the current message). On the contrary, when play mode=1 , the command is always 
current message based. See 'Possible error cases' below and clause 7.4.36.2 for more information. 

NOTE 3: For DTAM incoming messages, the message entry index in the list is used. For welcome messages, the 
message position index (specific field of the list) is used. 

NOTE 4: For a remote DTAM, the effect of a request for restarting or rewinding the playing of a message depends 
on the actual implementation of this functionality in the DTAM: it may be fully, partially, or not at all 
implemented. Partial support means for instance that the specified number of seconds might be only 
roughly respected. 

NOTE 5: If play mode = 0, <Number of seconds> shall be and ignored by the FP. 



Possible error cases: 

The FP shall answer the 'Play message' command with a negative acknowledgement (see clause 7.4.36.4.10) with one 
of the following reject reasons, in the indicated cases: 

Message list empty, if play mode = and 'Message type' is 'DTAM incoming message' and the DTAM 
incoming message list is empty (the Welcome message list is never empty). 

Message index too big, if play mode = and the message index value exceeds the number of available 
messages (either DTAM incoming or welcome messages, depending of 'Messages type'). 

Message index not allowed, if play mode = and the PP attempts to use the 'Play message' command with 
an index of indicating 'current message'. 

No message was being played, if play mode = 1, but no message was being played at command reception 
time. 
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7.4.36.4.4.2 'Play message confirm' command 

See table 75-46 and figure 80-5 below for details. 

Table 75-46: Values used within {IWU-INFO} message for the "Play message confirm" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 




<Protocol Discriminator> 


15H 


DTAM 




<Command = Play message 
confirm> 


09H 


DTAM command 




<DTAI\/I Session identifier> 


0..127 


Session identifier (see note) 


NOTE: 'DTAM session identifier' can be extended for values up to 16 383. See note 1 at table 39. 



pp 



FP 





DTAM consulting call established 

DTAM id = 1 

Call id = 3 






{IWU-INFO} 




« IWU-to-IWU Play message 

type='DTAM incoming message'» 

{IWU-INFO} 




« IWU-to-IWU Play message confirm » 






DTAM incoming message is played 















Figure 80-5: Use of the 'Play recorded message' command 



7.4.36.4.5 



Delete message 



7.4.36.4.5.1 



'Delete message' command 



The 'Delete message' command allows to delete the indicated DTAM incoming message or welcome message. See 
table 75-47 below. 
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Table 75-47: Values used within {IWU-INFO} message for the "Delete message" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 




<Protocol Discriminator> 


15H 


DTAM 




<Command = Delete message> 


OAH 


DTAM command 




<DTAM session identifier> 


0..127 


Session identifier (see note 1) 




<l\/lessages type> 



1 


DTAM incoming messages 
Welcome messages 




<Message index> 



1..127 


Current message should be deleted 
(see note 2) 

Index of the message that should be 
deleted (see note 1 ) 


NOTE 1 : 'DTAM session identifier' can be extended for values up to 16 383. See note 1 at table 39. 

NOTE 2: Message /ndex value '0' indicates use of the current message based variant of the command. For a safe 
use of the command, use of this variant is only allowed if no index is defined for the message (i.e. only for 
a voice oriented DTAIVI and if message type is DTAIVI incoming message). See 'Possible error cases' 
clause below, and clause 7.4.36.2 for more information. 



Possible error cases: 

The FP shall answer the 'Delete message' command with a negative acknowledgement (see clause 7.4.36.4.10) with one 
of the following reject reasons, in the indicated cases: 

Message list empty, if 'Message type' is 'DTAM incoming message' and the DTAM incoming message list is 
empty (the Welcome message list is never empty). 

Message index too big, if the message index value exceeds the number of available messages (either DTAM 
incoming or welcome messages, depending of 'Messages type'). 

Message index not allowed, if Message index value is while: 

the DTAM profile is 'Visual DTAM' (whatever the message type); 

or the DTAM profile is 'Voice oriented' and the message type is 'Welcome message'. 

No current message defined, if Message index value is while the DTAM profile is 'Voice oriented' and 
message type is 'DTAM incoming message', but no current message was defined at command reception time. 

7.4.36.4.5.2 'Delete message confirm' command 

See table 75-48 below. 

Table 75-48: Values used within {IWU-INFO} message for the "Delete message confirm" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 




<Protocol Discriminator> 


15H 


DTAM 




<Command = Delete message 
confirm> 


OBH 


DTAM command 




<DTAM session identifier> 


0..127 


Session identifier (see note) 


NOTE: 'DTAM session identifier' can be extended for values up to 16 383. See note 1 at table 39. 
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7.4.36.4.6 Pause/resume playing of message 

7.4.36.4.6.1 'Pause/resume playing of message' command 

This command from PP requests that the current playing of a message (DTAM incoming or welcome) be paused or 
resumed, depending on the current state of the playing (active or paused). 

NOTE: A paused message is still considered as being played. Playing may therefore still be stopped in paused 
state. 

See table 75-49 below. 

Table 75-49: Values used within {IWU-INFO} message 
for the "Pause/resume playing of message" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 




<Protocol Discriminator> 


15H 


DTAM 




<Command =Pause/resume 
playing of message> 


OCH 


DTAM command 




<DTAM session identifier> 


0..127 


Session identifier (see note) 


NOTE: 'DTAM session identifier' can be extended for values up to 16 383. See note 1 at table 39. 



Possible error cases: 

The FP shall answer the 'Pause/resume playing of message' command with a negative acknowledgement (see 
clause 7.4.36.4.10) with one of the following reject reasons, in the indicated cases: 

No message was being played, if no message was being played at command reception time. 

7.4.36.4.6.2 'Pause/resume playing of message confirm' command 

This command from FP confirms the pausing/resuming of current message playing. See table 75-50 below. 

Table 75-50: Values used within {IWU-INFO} message 
for the "Pause/resume playing of message confirm" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 




<Protocol Discriminator> 


15H 


DTAM 




<Command = Pause/resume 
playing of message confirm> 


ODH 


DTAM command 




<DTAM session identifier> 


0..127 


Session identifier (see note) 


NOTE: 'DTAM session identifier' can be extended for values up to 16 383. See note 1 at table 39. 



7.4.36.4.7 Stop playing message 

7.4.36.4.7.1 'Stop playing message' command 



This command from PP requests that the current playing of a message (DTAM incoming or welcome) be stopped. This 
command works whether the message was actually played, or if the playing was paused with 'Pause/resume playing of 
message'. See table 75-51 below. 



£75/ 



141 



ETSI TS 102 527-5 VI. 1.1 (2013-04) 



Table 75-51 : Values used within {IWU-INFO} message for the "Stop playing message" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 




<Protocol Discriminator> 


15H 


DTAM 




<Command =Stop playing 
message> 


10H 


DTAM command 




<DTAI\/I session identifier> 


0..127 


Session identifier (see note) 


NOTE: 'DTAM session identifier' can be extended for values up to 16 383. See note 1 at table 39. 



Possible error cases: 

The FP shall answer the 'Stop playing message' command with a negative acknowledgement (see clause 7.4.36.4.10) 
with one of the following reject reasons, in the indicated cases: 

No message was being played, if no message was being played at command reception time. 

7.4.36.4.7.2 'Stop playing message confirm' command 

This command from FP confirms the the request to stop current message playing. See table 75-52 below. 

Table 75-52: Values used within {IWU-INFO} message 
for the "Stop Playing Message confirm" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 




<Protocol Discriminator> 


15H 


DTAM 




<Command = Stop playing 
message confirm> 


11H 


DTAM command 




<DTAM session identifier> 


0..127 


Session identifier (see note) 


NOTE: 'DTAM session identifier' can be extended for values up to 16 383. See note 1 at table 39. 



7.4.36.4.8 



Record welcome message 



7.4.36.4.8.1 



'Record welcome message' command 



The 'Record welcome message' command allows the local user to request the recording of a new welcome message at 
the indicated welcome message index. If a welcome message was already recorded for this index, it is replaced with the 
new message. See table 75-53 below. 

Table 75-53: Values used within {IWU-INFO} message 
for the "Record new welcome message" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 




<Protocol Discriminator> 


15H 


DTAM 




<Command = Record welcome 
message> 


12H 


DTAM command 




<DTAM session identifier> 


0..127 


Session identifier (see note) 




<Message position index> 


1..127 


Position index of the welcome 
message that is recorded (see 
note 1 ) 


NOTE: This field can be extended for values up to 1 6 383. See note 1 at table 39. 
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Possible error cases: 

The FP shall answer the 'Record welcome message' command with a negative acknowledgement (see 
clause 7.4.36.4.10) with one of the following reject reasons, in the indicated cases: 

Message index to big, if the message position index value exceeds the maximum number of welcome 
messages available for the DTAM (see clause 7.4.36.5.1.6). 

NOTE: Welcome messages with index between 1 and this maximum always exist (but may be empty), so that the 
message index always exists for them. 

Message index not allowed, if the PP attempts to use the 'Record welcome message' command with an index 
of indicating 'current message'. 

7.4.36.4.8.2 'Record welcome message confirm' command 

See table 75-54 below. 

Table 75-54: Values used within {IWU-INFO} message 
for the "Record welcome message confirm" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 




<Protocol Discriminator> 


15H 


DTAM 




<Command = Record welcome 
message confirm> 


13H 


DTAM command 




<DTAM session identifier> 


0..127 


Session identifier (see note) 


NOTE: 'DTAM session identifier' can be extended for values up to 16 383. See note 1 at table 39. 



7.4.36.4.9 



Stop recording welcome message 



7.4.36.4.9.1 



'Stop recording welcome message' command 



The 'Stop recording welcome message' command allows the local user to indicate to the DTAM that recording shall be 
terminated (i.e. welcome message was entirely recorded). See table 75-55 below. 

Table 75-55: Values used within {IWU-INFO} message 
for the "Stop recording welcome message" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 




<Protocol Discriminator> 


15H 


DTAM 




<Command = Stop recording 
welcome message> 


14H 


DTAM command 




<DTAM session identifier> 


0..127 


Session identifier (see note) 


NOTE: 'DTAM session identifier' can be extended for values up to 16 383. See note 1 at table 39. 



Possible error cases: 

The FP shall answer the 'Stop recording welcome message' command with a negative acknowledgement (see 
clause 7.4.36.4.10) with one of the following reject reasons, in the indicated cases: 

No message was being recorded, if no welcome message was being recorded at command reception time. 
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7.4.36.4.9.2 'Stop recording welcome message confirm' command 

See table 75-56 below. 

Table 75-56: Values used within {IWU-INFO} message 
for the "Stop recording welcome message confirm" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 




<Protocol Discriminator> 


15H 


DTAM 




<Command = Stop recording 
welcome message confirm> 


15H 


DTAM command 




<DTAM session identifier> 


0..127 


Session identifier (see note) 


NOTE: 'DTAM session identifier' can be extended for values up to 16 383. See note 1 at table 39. 



7.4.36.4.10 



Negative acknowledgement 



This command from the FP rejects the previous command with a reject reason, and is sent instead of the regular 
command confirmation. 

The FP shall wait until the erroneous command is completely received from the PP before replying with a negative 
acknowledgement. See table 75-57 below. 

Table 75-57: Values used within {IWU-INFO} message 
for the "Negative Acknowledgement" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 


<Protocol Discriminator> 


15H 


DTAM 


<Command=negative 
acknowledgement > 


40H 


DTAM command 


<DTAM session identifier> 


1..127 


Session identifier (see note) 


<Reject reason> 


0..255 


Reject reason 


NOTE: 'DTAM session identifier' can be extended for values up to 16 383. See note 1 at table 39. 



Reject reason: 

Bits 87654321 Meaning 

00000000 Unknown error 

1 Message Ust empty 

10 Message index not allowed 

1 1 Message index too big 

00000100 No current message defined. 

00000101 No message was being played 

000001 10 No message was being recorded 
000001 1 1 End of message list reached 

00001000 Beginning of message list reached 

00001001 Command not implemented 
all other values reserved 

In the case of 'invalid session number', the invalid session identifier of the acknowledged command is used in the 
negative acknowledgement. 
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7.4.36.4.11 



DTAM status command 



This command from the FP is sent after the regular command confirmation in some circumstances in order to inform the 
PP of the current DTAM status, especially concerning the currently handled message. See table 75-58 below. 

Table 75-58: Values used within {IWU-INFO} message for the "DTAM status" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 


<Protocol Discriminator> 


15H 


DTAM 


<Command= DTAIVI status > 


41H 


DTAM command 


<DTAM session identifier> 


1..127 


Session identifier (see note) 


<DTAM status> 


0..255 


DTAM status 


NOTE: 'DTAIVI session identifier' can be extended for values up to 16 383. See note 1 at table 39. 



DTAM status: 



Bits 87654321 Meaning 

00000000 Reserved 

00000001 Message playing has ended 
00000010 Message maximum recording time was reached 
all other values reserved 



7.4.36.5 



DTAM related lists 



7.4.36.5.1 


DTAM specific fields descript 


on 










7.4.36.5.1.1 


DTAM full identifier 




See table 75-59. 


Table 75-59: DTAM full identifier 




Bits 


8 


7 |6|5|4|3|2|1 


Octet 







Field identifier = DTAM full identifier 


1 




0/1 


Length (L) 


2 




0/1 


Editable 


X 


X 


X 


X 


Voice/ 
Visual 


PIN 
protected 


3 




0/1 ext 


DTAM 
location 


DTAM id 


4 



Voice/Visual property (octet 3). The voice visual property indicates (when unset) if the DTAM is Voice-oriented (see 
clause 7.4.36.2.1) or (when set) a Visual DTAM (see clause 7.4.36.2.2). 

DTAM location (octet 4) 

Bits 7654321 Meaning 

X X X X X X Local DTAM 

1 X X X X X X Remote DTAM 
DTAM id (octet 4) 

DTAM id shall be unique within all DTAMs used by the DECT system, whether local or remote. DTAM id value shall 
be in the interval 0..63. 
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7.4.36.5.1.2 



Field 'DTAM Number' 



The DTAM number field shall contain a single phone number value that is used when establishing a DTAM consulting 
call with the DTAM. 

This field may be empty in two cases: 

• The DTAM has no number; this happens in the following cases: 

The DTAM is local to the FP. 

The DTAM is remote but is accessed by the FP through a server API (e.g. HTTP or Web Service 
interface). 

• The DTAM has a number, but the number is supplied by the user as keypad information when establishing the 
DTAM consulting call. 

For the format of this field, see 'Number' field in "List access service" feature, clause 7.4.10.5.1.2, except that the 
possible value will be in the interval '30'H..'39'H, plus the '2A'H value. 

The field 'DTAM Number' may be protected against unauthorized modification by the FP by use of the 'PIN protected' 
property (see clause 7.4.10.5.1.2). 



7.4.36.5.1.3 



Field 'Local DTAM current PIN code' 



Detailed use of the 'Local DTAM current PIN code' is described in clause 7.4.36.5.6. The 'Local DTAM current PIN 
code' field shall be coded as in table 75-60. 

Table 75-60: 'Local DTAM current PIN code' field 



Bits 



8 


7 6 


5 4 3 2 


1 




Field identifier 


= 'Local DTAIVI current PIN code' 




0/1 


Length (L) 


0/1 


Editable 


X 


X 


X 


X 


X 


PIN 

protected 

= 1 


l^'byte 


2™ byte 


3'" byte 


4'" byte 



Octet 

1 
2 
3 



7.4.36.5.1 .4 Field 'DTAM activation and timeout' 

The ' DTAM activation and timeout' field shall be coded as in table 75-61. 

Table 75-61 : 'DTAM activation and timeout' field 
Bit: |8|7|6|5|4|3|2|1 



Octet: 



Field identifier = DTAM activation and timeout 


1 


0/1 


Length (L) 


2 


0/1 


Editable 


X 


X 


X 


X 


X 


PIN 

protected 


3 


Deactivated / Activated 


4 


default 
timeout 


DTAM timeout 


5 



Length octet (octet 2): The value of the length (L) indicator shall be equal to '2'. 

'PIN protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect (or not) the 'DTAM 
activation and timeout' field against unauthorised modification, depending on its security policy. 
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'Deactivated/Activated' octet (octet 4). The 'Deactivated/ Activated' octet shall be 30H or 31H. 30H stands for DTAM 
deactivated for that line, 31H for DTAM activated for that line. 

Some DTAMs may not allow activation line by line. In that case, the 'Deactivated/ Activated ' octet value shall be the 
same for all lines associated with that DTAM. 

'Default timeout' bit (bit 8 of octet 5). The 'default timeout' bit indicates (if set) that the configured DTAM timeout is 
the FP default timeout value. If the bit is set, the following 'DTAM timeout' value shall be disregarded. 

DTAM timeout (octet 5). The DTAM timeout is the number of seconds before DTAM answers an incoming call. The 
DTAM timeout shall be coded with the natural binary value, with the least significant bit in bit position "1". Allowable 
values are to 127. 

A value of zero indicates a timeout of '0' seconds, meaning that the DTAM is configured to answer incoming calls 
immediately. 

Some DTAMs may not allow different values from one line to another. In that case, the FP shall ensure that the DTAM 
timeout is the same for all lines associated with that DTAM: if the PP user modifies the value for one line, the FP shall 
copy the new value to all other corresponding line settings. 



7.4.36.5.1.5 



Field 'DTAM web link' 



The 'DTAM Link' field sets the address of the DTAM location on the network. The 'DTAM Link' field shall be coded as 
in table 75-62. 

Table 75-62: 'DTAM web link' field 



Bits 



8 


7 


6 1 5 1 4 1 3 


2 


1 


Octet 


Field identifier = DTAM web link 


1 


0/1 


Length (L) 


2 


0/1 


X 


X 


X 


X 


X 


X 


PIN 
protected 


3 


1 ^' character byte 


4 


2™ character byte 


5 







'PIN protected' (bit 1 of octet 3). This allows the FP to protect the 'DTAM web link' field against unauthorized 
modification, depending on its security policy. 

Characters will be coded as defined for UTF-8 but restricted to the IA5 subset of characters (code point below or equal 
to 127). The max. length of this parameter (from octet 4) shall be 2 048. 

Bits 2 to 7 (octet 3): reserved for further standardization and will be set to "0". 



7.4.36.5.1 .6 Field 'Welcome message parameters' 

The 'Welcome message parameters' field shall be coded as in table 75-63 below. 

Table 75-63: 'Welcome message parameters' field 
Bit: |8|7|6|5|4|3|2|1 



Field identifier = Welcome message parameters 


0/1 


Length (L) 


0/1 


Editable 


X 


X 


X 


X 


X 


PIN 

protected 


0/1 


Selected welcome message position index 



Octet: 

1 
2 
3 



Length octet (octet 2): the value of the length (L) indicator shall be > '3'. The field shall always contain all of the 
indicated subfields, even if the 'is_DTAM' bit (see below) is not set. 

'PIN protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect (or not) the 'Welcome 
message parameters' field against unauthorised modification, depending on its security policy. 
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'Selected welcome message position index' (octet 4). This subfield allows the PP user to indicate which welcome 
message shall be used for the line (starting from 1). The position index value shall correspond to the position index in 
the 'DTAM Welcome Message List' of the selected welcome message (see clause 7.4.36.5.4). 

EXAMPLE: If the DTAM only supports one welcome message, the subfield shall contain a (non-editable) 
value of 1 . 

Some DTAMs may not allow to select a welcome message per line (e.g. welcome message selection could be based on 
time only). In that case, the 'Selected welcome message index' subfied shall be the same for all lines associated with that 
DTAM; if the PP user modifies the value for one line, the FP shall copy the new value to all other corresponding line 
settings. 



7.4.36.5.1.7 
See table 75-64. 



Field 'Screening parameters' 



Table 75-64: 'Screening parameters' field 



Bits 



8 


7 1 6 1 5 1 4 1 3 1 2 


1 


Octet 





Field identifier = Screening parameters 


1 


0/1 


Length (L) 


2 


0/1 


Editable 


X 


X 


X 


X 


X 


PIN 
protected 


3 


Screening deactivated / activated on FP side 


4 


Single PP / multiple PPs call screening mode 


5 


Screening acceptance timeout 


6 


1 


Number of screening handsets 


7 


0/1 


Handset bitmap 


8 


0/1 






1 


Handset bitmap (continued) 


8n 



PIN protected (bit 1, octet 3) allows the FP to protect the Screening support field against unauthorized modification, 
depending on its security policy. 

Bits 2 to 6 (octet 3): These bits are reserved for further standardization and shall be set to 0. 

'Screening deactivated/activated on FP side' octet (octet 4). This one-octet subfield indicates the screening activation 
status on FP side for the line. Value 30H stands for screening deactivated for the line on FP side, 31H for screening 
activated for the line on FP side. 

Some DTAMs may not allow screening activation line by line. In that case, the subfield value shall be the same for all 
lines associated with the DTAM. 

'Single PP/ multiple PPs call screening mode' octet (octet 5). This one-octet subfield indicates whether the FP is in 
'single PP' of 'multiple PPs' screening mode for the line. Value 30H stands for single PP for the line, 31H for multiple 
PPs for the line. 

A FP that cannot manage multiple PPs in call screening mode shall always use value 30H for this subfield. 

Some DTAMs may not allow the use of different modes from one line to the other. In that case, the subfield value shall 
be the same for all lines associated with the DTAM. 

Screening acceptance timeout (octet 6). The screening acceptance timeout is the number of seconds starting from call 
screening indication (clause 7.4.36.6.2) before the FP releases the call screening presentation to a PP (using 
clause 7.4.36.6.6). The timeout shall be coded with the natural binary value, with the least significant bit in bit position 
"1". Allowable values are to 255. 

A value of zero indicates that the default value configured in the FP shall be used. 

Some DTAMs may not allow different values from one line to another. In that case, the FP shall ensure that the timeout 
is the same for all lines associated with the DTAM: if the PP user modifies the value for one line, the FP shall copy the 
new value to all other corresponding DTAM settings entries. 
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Number of screening handsets (octet 7). The number of screening handsets relates to the number of handsets that are: 
screening capable, 
attached to the considered line, and 
activated for screening on that line thanks to the following bitmap. 

The value shall be coded with the natural binary value, with the least significant bit in bit position " 1 " . Allowable values 

are "1" to "127". 

Handset bitmap (octet group 8). This is a bitmap octet group, with handset number 1 in bit position 1, etc. A value of 1 
indicates an activated screening-capable handset attached to the line, and a "0" indicates it is not. 

Bits 7654321 Meaning 

X X X X X X 1 Handset number 1 is an activated screening capable handset attached to the line 

X X X X X 1 X Handset number 2 is an activated screening capable handset attached to the line 

X X X X 1 X X Handset number 3 is an activated screening capable handset attached to the line 

X X X 1 X X X Handset number 4 is an activated screening capable handset attached to the line 

X X 1 X X X X Handset number 5 is an activated screening capable handset attached to the line 

X 1 X X X X X Handset number 6 is an activated screening capable handset attached to the line 

1 X X X X X X Handset number 7 is an activated screening capable handset attached to the line 



NOTE 1 : If extension bit is in the first octet (indicating presence of an additional octet), the least significant bit of 
second octet stands for handset number 8. 

NOTE 2: The format of the current field is a bitmap; it differs from 'Number' field format of the Internal Names 
List (terminal id number) but represents the same handset numbers. 

The FP shall control that only screening capable handsets attached to the line are activated through the bitmap. 

Only the necessary number of octets shall be transmitted over the air within the octet group, depending directly on the 
number of registered handsets. It is not necessary to transmit all 19 octets of the octet group (covering the 127 
positions). As a particular case, if there is no screening handset for the line: 

• the 'Number of Screening handsets' shall be set to 0. 

• no handset bitmap octet will be included in the field. 



7.4.36.5.1.8 
See table 75-65. 



Field 'Time duration' 



Table 75-65: Time duration' field 



Bits 



8 


7 


6 1 5 1 4 1 3 1 2 1 1 


Octet 


Field identifier = Time duration 


1 


0/1 


Length (L) 


2 


0/1 


editable 


X 


X 


X 


X 


X 


PIN 
protected 


3 


<Hours in BCD format> 


4 


<l\/linutes in BCD format> 


5 


<Seconds in BCD format> 


6 



For octet 3, each bit indicates whether a property of the field is given (1) or not (0). In the case of 'x', the value is 
reserved for future use. 

Hours/Minutes/Seconds (octets 4,5 and 6). Contain the time duration in hours, minutes and seconds in BCD format. 

EXAMPLE: A duration of 1 hour 22 minutes and 2 seconds shall be coded with octet 4 = OIH (hour), octet 5 
22H (minute), octet 6 = 02H (second). 



£75/ 



149 



ETSI TS 102 527-5 VI. 1.1 (2013-04) 



NOTE: Octets 4, 5 and 6 coding is identical to «Time-Date» IE (see EN 300 175-5 [5], clause 7.7.50) for the 
same octets with 'coding' sub field value 'Ol'B ('Time') and 'interpretation' subfield value '00000 1'B ('Time 
duration'). 



7.4.36.5.1.9 



Field 'Local DTAM new PIN code' 



Detailed use of the 'Local DTAM new PIN code' is described in clause 7.4.36.5.6. The 'Local DTAM new PIN code' 
field shall be coded as in table 75-66. 

Table 75-66: 'Local DTAM new PIN code' field 



Bits 


8 1 7 1 6 


5 1 4 1 3 1 2 


1 


Octet 




Field identifie 


r = Local DTAM new PIN code 




1 




0/1 


Length (L) 


2 




0/1 


Editable 


X 


X 


X 


X 


X 


PIN 

protected 

= 1 


3 




l^'byte 


4 




2™ byte 


5 




3™ byte 


6 




4'" byte 


7 


7.4.36.5.1.10 


Field 


'Positio 


1 index' 















This field is used for indicating the DTAM position used for storing the (possibly empty) recorded message. See 
table 75-67. 

Table 75-67: 'Position index' field 



Bits 



8 


7 


6 1 5 1 4 1 3 


2 


1 1 


Field identifier = Position index 


0/1 


Length (L) | 


0/1 


editable 


X 


X 


X 


X 


X 


PIN 
protected 


Position index value 



Octet 
1 
2 
3 



The Position index value shall be in the interval [1 .. N], where N is the number of available positions in the considered 
DTAM for storing DTAM welcome messages. N shall not exceed 255. 
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7.4.36.5.2 DTAM Settings List 

The DTAM Settings List contains one entry for each Hne-DTAM association. 

Any non Hne specific DTAM parameter value shall therefore be repeated for each line using the concerned DTAM. 

See table 75-68 below. 

Table 75-68: Entry fields for the DTAM Settings List 



Field 
identifier 


Field 


Length 
constraint 


Normative action/comment 


Clause 


01H 


Line id 


>1 


Line id of the Line-DTAM association 


7.4.10.5.1.7 


02H 


DTAM full 
identifier 


= 3 


DTAM location and DTAM id of the line- 

DTAM association 

Includes the Voice/Visual property 


7.4.36.5.1.1 


03H 


DTAIVI Number 


> 1 


The number to call DTAM 


7.4.36.5.1.2 
7.4.10.5.1.2 


04H 


Local DTAM 
current PIN code 


= 5 


Current PIN code of the local DTAM used 
for checking PIN code entered by user 


7.4.36.5.1.3 


05H 


DTAM activation 
and timeout 


> 1 


Allows to activate/deactivate the DTAM 
for the indicated line (for all lines) and 
define the used DTAM timeout 


7.4.36.5.1.4 


06H 


DTAM web link 


>1 


The link to connect DTAM 


7.4.36.5.1.5 


07H 


Welcome 
message 
parameters 


>1 


Selected message for the indicated line 


7.4.36.5.1.6 


08H 


Screening 
parameters 


>5 


Screening parameters for the indicated 
line-DTAM association 


7.4.36.5.1.7 


09H 


Local DTAM 
new PIN code 


= 5 


New PIN code of the local DTAM used to 
modify the PIN code 


7.4.36.5.1.9 



7.4.36.5.2.1 Entry fields statuses for local and remote DTAMs 

See table 75-69 below. 

Table 75-69: Entry field statuses for the DTAM Settings List 



Field 
identifier 


Field 


Local DTAM 
Status 


Remote DTAM Status 


01H 


Line id 


M 


M 


02H 


DTAM full identifier 


M 


M 


03H 


DTAM Number 


M (note 1 ) 


M (note 2) 


04H 


Local DTAM PIN code 





NA 


05H 


DTAM activation and 
timeout 


M 


M 


06H 


DTAM web link 


M (note 2) 


M (note 2) 


07H 


Welcome message 
parameters 


M 


M 


08H 


Screening parameters 





NA 


09H 


Local DTAM new PIN 
code 





NA 


NOTE 1 : The field shall always be empty. 

NOTE 2: The field is mandatory but may be empty. 



7.4.36.5.3 DTAM Incoming Calls List 

The DTAM Incoming Calls List shall contain the following fields. 

NOTE: The DTAM Incoming Calls List is only used by Visual DTAMs (see clause 7.4.36.2). 
See table 75-70 below. 
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Table 75-70: "DTAM Incoming Calls List" entry fields 



Field 
identifier 


Field 


Length 
constraint 


Normative action/comment 


Clause 


01H 


DTAM full 
identifier 


=3 


DTAM location + DTAM id + DTAM 
Visual/voice property 


7.4.36.5.1.1 


02H 


Number 


>1 


Number of the calling party 


7.4.10.5.1.2 


03H 


Name 


>1 


Name of the calling party 


7.4.10.5.1.3 


04H 


Date and Time 


>5 


Date and time of the DTAM incoming call 


7.4.10.5.1.4 


05H 


Read status 


= 1 


Indicates whether entry is shown first time 


7.4.10.5.1.5 


06H 


Line name 


>2 


Name of line on which the call was 
received (cannot be empty) 


7.4.10.5.1.6 


07H 


Line id 


>3 


Id of line on which the call was received 


7.4.10.5.1.7 


08H 


Time duration 


= 5 


Message time duration 


7.4.36.5.1.8 



7.4.36.5.4 



DTAM Welcome Message List 



The "DTAM Welcome Message List" contains for each DTAM one entry per available position in the DTAM for 
recording a welcome message. 

The number of positions (number of entries in the list with corresponding DTAM id) shall always correpond to the 
maximum number of welcome messages supported by the DTAM and should remain stable over time. In order to 
remove a welcome message, the PP user may empty the position by setting the message time duration to 0. 

NOTE 1: Another way to remove a message is to replace it with another one, using the DTAM command 'Record 
welcome message' at the corresponding entry index. 

The list shall contain the fields indicated in the following table 75-71. 

NOTE 2: The DTAM Welcome Message List is used for both DTAM profiles (Voice oriented and Visual 
DTAMs). 

Table 75-71 : "DTAIUI Welcome IVIessage List" entry fields 



Field 
identifier 


Field 


Length 
constraint 


Normative action/comment 


Clause 


01H 


DTAM full 
identifier 


= 3 


DTAM location + DTAM id + DTAM 
Visual/voice property=1 (Visual DTAM) 


7.4.36.5.1.1 


02H 


Position index 


>1 


Index of the position in the DTAM holding 
the recorded message 


7.4.36.5.1.10 


03H 


Name 


> 1 


Label of the recorded message 


7.4.10.5.1.3 


04H 


Time duration 


= 5 


Message time duration 

is used of no message is recorded for 

the position 


7.4.36.5.1.8 



NOTE 3: The DTAM Settings List is used in order to select the welcome message used for a line (or several lines). 



7.4.36.5.5 



List Access service call transformation into a DTAM consulting call 



The present clause applies to a PP involved in an LiA service call not already transformed into a voice call. It does not 
apply to an LiA session started within a voice call. 

In order to transform an LiA service call into a DTAM consulting call, the PP shall use control code 1C20H together 
with the targeted DTAM id. The LiA session may continue, or may be ended. 

EXAMPLE: Figure 80-6 describes LiA access to the DTAM Settings List, transformed into a DTAM 

consulting call. The DTAM id is found in the DTAM Settings List itself Transformation of an 
LiA access to the DTAM incoming list could also be used. 

NOTE: In principle, LiA access to any list can be tranformed into a DTAM consulting call, provided that the PP 
knows the DTAM id. However, the most probable use case involves LiA access to a DTAM relating list. 
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Basic service change. The basic service shall implicitly change from 'LiA service call' into 'DTAM wideband speech 
default setup attributes' indicating a 'DTAM consulting call' (see clause 7.4.36.3.1). 

Call class change. The call class shall implicitly change to adapt to the DTAM location (see clause 7.4.36.3.1). 

Subsequent LiA session with DTAM Incoming Calls List. If the DTAM is a Visual DTAM, an LiA session with the 
DTAM Incoming Calls List should be started (if it was not already started in the initial LiA session) within the 
established DTAM consulting call, as described in clause 7.4.36.3.1 (subsection 'LiA session within DTAM consulting 
call'). 
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PP 



FP 



{CC-SETUP} 



« BASIC SERVICE, 
<basic service = 'Wideband speech default setup attributes'> 
<cal I class = 'LiA service call' > » 

{CC-CALL-PROC} 



NO <<CALL-INFORMATION» here, because 

no call Id is used for a list access service call 
no 'CS call proc' call status either 



LiA session (e.g. with Line settings List for retrieving Line id) 



Pseudo outgoing parallel DTAM consulting (voice) call initiation 
{CC-INFO} 



<< MULTI-KEYPAD, <Keypad info = '1C20'H + 'Line id' > » 
PP possibly ends the LiA session 



{CC-CONNECT} 



U-planeopen 



CODEC-LIST : 



Service call: 
No call id used 



NoCC-SETUP-ACK 



no call hold in return 



Implicit basic service 
and call class change 



Use of Line id for identifying DTAIVI (local or remote) + optional DTAM number 

{CC-INFO} 



<< IVIULTI-KEYPAD, < Keypad info = or 'DTAIVI number' 
« CALL-INFORMATION, call id=3, line id identifying DTAM» 

{CC-INFO} 



« CALL-INFORMATION, call id=3 call status = 'CS call proc' » 
{CC-INFO} 



« CALL-INFORMATION, call id=3, call status = 'CS call alerting' >: 
{CC-INFO} 



« CALL-INFORMATION, call id=3, call status = 'CS call connect' > 



{IWU-to-IWU} 



« Start DTAM session <Line id> >> 
{IWU-to-IWU} 



« Start DTAM session confirm >> 



For aVisual DTAM (if DTAM incoming messages are managed) 

{IWU-to-IWU} 



<< Start LiA session <DTAM incoming call list>>> 
{IWU-to-IWU} 



« Start LiA session confirm » 
DTAM incoming call list retrieval for messages management 



start outgoing call 
towards remote DTAM 



Call idassignement 
here 



DTAM consulting call 
starts here 



Included DTAM 
session is started 



Alternatively the 
'welcome message 
list may be opened 



Figure 80-6: DTAM consulting (voice) call establishment from LiA service call 



£75/ 



154 ETSI TS 102 527-5 VI. 1.1 (2013-04) 

7.4.36.5.6 Local DTAM PIN code management 

The local DTAM PIN code works similarly to the Line Settings List PIN code described in clause 7.4. 11.1. 
Two distinct fields are defined in the 'DTAM settings' list: 

• The 'Local DTAM current PIN code' field (see clause 7.4.36.5.1.3) is only used to check the PIN code entered 
by the user. As it is not directly modifiable, it is not considered as 'PIN protected'. 

• The 'Local DTAM new PIN code' field (see clause 7.4.36.5.1.9) is used to modify the PIN code and is 
therefore always 'PIN protected'. If the field is modified, the new value shall be stored in both PIN code fields. 

Both fields are protected against reading: after any 'edit entry' or 'read entry' command on any of these two fields, the 
FP shall answer with the invalid value 'FFFFFFFF'H, instead of the real value of the field. 

Line dependency. The DTAM Settings List allows the definition of one PIN code per line. When a DTAM used on 
several lines does not allow the use of one PIN code per line, the PIN code shall protect the whole DTAM (it is at least 
true for voice-oriented DTAMs). 

PIN checking. PIN checking involves opening a session with the DTAM Settings List and using 'edit entry'/'save entry' 
with the 'current' PIN code field. The save entry command shall only contain the 'current PIN code' field. The save entry 
command has a special behaviour in this context, as it does not modify the stored field but only compares the sent value 
with the stored value. PIN check is successful if the value inserted in the 'save entry' command is correct; otherwise a 
negative acknowledgement with reject reason 'incorrect PIN' is used. 

Only the PP initiating PIN checking shall be allowed to perform protected operations. 

PIN code protected operations. 

Protected operation shall include: 

• Modification or deletion of PIN protected fields in the 'DTAM settings' and 'DTAM incoming call' list: 

the subset of PIN -protected fields within these lists is left free to the implementer. However, The 'Local 
DTAM new PIN code' shall always be PIN protected. 

• Operations implying protected fields deletion (i.e. list or list entry deletion). 

• Reading access to the 'DTAM incoming call' list and to the DTAM Welcome Message List. 

• DTAM session creation (this includes use of DTAM commands within that session and listening of messages). 

NOTE 1: Reading access to the 'DTAM settings' list is not PIN protected. However the PIN code fields values are 
protected through the invalid returned value. 

NOTE 2: Possible use of the same PIN code for protecting remote access to the local DTAM is out of scope of the 
present document. 

Absence of prior PIN checking in the same call. In the case where no successful PIN checking took place before a 
protected operation within the same call: 

• The FP shall answer a 'start DTAM session command' with DTAM start session reject reason 'PIN code 
required' (see clause 7.4.36.4.2.2). 

• The FP shall answer a protected LiA command with a negative acknowledgement with reject reason 'PIN code 
required' (see clause 7.4.10.4.9). 

Ciphering. For security reasons, both PIN code fields from PP to FP shall never be sent over the air on a non-ciphered 
link. If this is not the case, the FP shall answer the 'save entry' with a negative acknowledgement, with reject reason = 
"procedure not allowed" (see clause 7.4.10.4.9). 
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7.4.36.6 Call Screening 

7.4.36.6.1 Screening general requirements 

Call screening applies to an external incoming call received on a line with an associated DTAM, and for which no user 
of the DECT system answered the call within the configured DTAM timeout (see clause 7.4.36.4.14). 

Call screening. Call screening is used in addition to the recording of the DTAM incoming call, to allow users to listen 
to the call while it is being recorded, and without answering it. The screening PP is muted and the audio is routed to the 
speaker (or earpiece). 

Call screening indication. Renewed presentation of the call when answered by a DTAM with call status 'CS screening 
setup', so that the PP can accept the screened call and call screening can begin with that PP. 

Call screening acceptance. Acceptance by a PP receiving a call screening indication of the call in screening mode. 
This acceptance may be either automatic or manual depending on the PP configuration. 

Call screening interception. During call screening, the user intercepts the call and joins it, continuing the incoming 
call as a regularly answered call. Recording of the call is stopped. 

Screening-capable PP. PP that is able to accept (or reject) a call in screening mode (see clause 7.4.36.6.3). Call 
screening acceptance involves in particular opening the loudspeaker and muting the microphone. 

A screening capable PP shall indicate so by indicating 'Support of DTAM and Screening features' in the terminal 
capability information element. 

Screening PP. Screening capable PP that is activated for screening on the considered line (see 'Screening parameters' in 
clause 7.4.36.5.1.7) and therefore receives call screening indications. 

NOTE: If screening is indicated via a 'CS screening setup' to screening PPs, non activated screening-capable PPs 
are handled like non screening capable PPs and receive an FT initiated call screening release (see 
clause 7.4.36.6.6). 

Screened call. Call for which the screening PPs attached to the line of the external incoming call receive a call 
screening indication that the call may be accepted in screening mode. 

Summary of PP side states for a first or parallel call. The screening-specific states and other regular states of an 
external incoming call, and their relations with the screening-specific and other regular control codes are summarized 
below in figure 80-7. 
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Call idle 



T 



User reject/ send 1C36H (call waiting rejection) 
CS call setup or {CC-RELEASE-COM}(firstcall rejection) 
(see note 1) 
I 



User release /send 1C33 (parallel call) 

or{CC-RELEASE}(firstcall) 

(see note 2) 



Call presented 



Call presented 



CS screening setup 



Call presented 
for screening 



Pick up /send {CC-CONNECT}(first call 
orlC35H (second call) 



i 



Accept screening (manual orautomated) 
/send 1C48H +{CC-CONNECT}(firstcall 
orlC48H (parallel call) 



Connect 
waiting 



CS screening setup Pick up screened call (see note 3) 
(see note 3) /send {CC-CONNECT}(firstcall) 

or 1C35H (second call) 



Screening connect 
waiting 



CS call connect 



CS screening 
connect 



Call connected 



Call 
connected 



CS call connect 



Connect 
waiting 



Pick up /send 1C49H 



Call connected 
for screening 



NOTE 1 : Call waiting rejection (1 C36H) can still be used if a parallel call is presented for screening ('CS screening 

setup' has been received). 
NOTE 2: Parallel call release (1 C33H) can still be used if call is connected for screening ('CS screening connect' 

has been received). In that case, the call becomes idle on the DECT system as a result of the release, but 

not idle end-to-end (DTAM recording continues). 
NOTE 3: Crossing of call pick-up from user and 'CS screening setup' from FP is solved by cancelling screening 

presentation. 
NOTE 4: In order to accept a first incoming call without screening, {CC-CONNECT} alone is allowed in 'Call 

presented' and 'Call presented for screening' states, while call screening interception (1C49H) is allowed in 

'Call connected for screening' state. 
NOTE 5: In order to accept a parallel incoming call without screening, 'Call waiting acceptance' (1 C35H) is allowed 

in 'Call presented' and 'Call presented for screening' states, while call screening interception (1C49H) is 

allowed in 'Call connected for screening' state. 

Figure 80-7: Summary of PP side states for a first or parallel screened call. Crossing cases 



7.4.36.6.2 



Call screening indication (FP to PP) 



Call screening indication may be sent by the FP after an external incoming call was first presented (as a regular external 
incoming call) and not answered within DTAM timeout. 

Call screening can be seen as a second presentation of the call to the PP (i.e. with 'CS screening setup' call status instead 
of 'CS call status') after the initial regular incoming call presentation (with 'CS call setup') was not answered by any user 
within DTAM timeout. 

NOTE 1 : Call screening indication should not occur before the associated DTAM answers the call. 

For a first external incoming call, call screening indication (to all screening PPs not already involved in a call) occurs 
after regular call presentation (to all PPs) as follows: 

The FP sends a {CC-SETUP} message, with call status 'CS call setup' to the PP. 

The PP returns a {CC-ALERTING} message. 

The FP starts playing the welcome message towards the remote user (i.e. even if U-plane is not connected). 
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At the time of call screening indication: 



For a screening PP, the FP sends a call screening indication to the PP by sending call status 'CS 
screening setup' within a {CC-INFO} message indicating that call screening has started. 

For a non-screening PP, the FP sends a {CC-RELEASE} from the FP. 

NOTE 2: Non-screening PPs include non screening-capable PPs, and screening-capable PPs that are not activated. 

A screening PP that receives a call screening indication has the following options: 

Accept the screened call (can be done automatically or manually); see clause 7.4.36.6.3. 

Reject the screened call (user initiated rejection; see clause 7.4.36.6.4). 

Pick up the call as a regular external incoming call (in which case DTAM recording and screening stop). 

Ignore the screened call, that is, neither accept, reject, nor pick up the call (only possible if call screening 
acceptance is configured as manual). 

NOTE 3: The case of a waiting call is described in clause 7.4.36.6.8. 
7.4.36.6.3 Call screening acceptance (PP to FP) 

The screened call (i.e. the second presentation of the call in call screening mode with call status 'CS screening setup') 
can be accepted by the PP by use of a 'call screening acceptance'. 

After the screened call has been accepted by a sceening PP, call screening can begin with that PP. All other PPs receive 
a {CC-RELEASE} message. 

A screened call can be accepted automatically or manually by the user. 

For accepting a screened call (either manually or automatically), the PP shall use a call screening acceptance control 
code ('1C48'H) in a «MULTIKEYPAD» IE sent to the FP within a {CC-INFO} message (see also clause 7.4.3.2). 

Single PP call screening mode. If an FP only supports a single PP in screening mode, or if the FP is configured in 
single PP screening mode, the FP shall release the screened call for all other PPs by using the 'FP initiated call screening 
release' procedure (see clause 7.4.36.6.6). 

Multiple PPs call screening mode. See clause 7.4.36.6.10. 

See figure 80-8 below for an example. 
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PP 



FP 



CC-SETUP 



« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call setup' > 
» 

CC-ALERTING 



« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 
» 

FP starts playing of Welcome 
message towards remote user 

Call screening indication 
CC-INFO 



« CALL-INFORMATION, 
<id type/subtype = 'Call identifier', value=01 H> 
<id type/subtype='line id/external call', value = u> 
<id type/subtype = 'Call status', value='CS screening setup' > 
» 

DTAM incoming call 
automatically accepted 

Call screening acceptance 

CC-INFO 



« MULTI-KEYPAD, <Keypad info = 1C48H > » 
« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 
» 

CC-CONNECT 



« CALL-INFORMATION, 
<id type/subtype='Call identifier', value = 01 H > 
» 

CC-CONNECT-ACK 



« CALL-INFORMATION, 
<id type/subtype='Call identifier', value = 01H > 



CC-INFO 



« CALL-INFORMATION, 
<id type/subtype='Call identifier', value = 01 H > 
<id type/subtype='line id/external call', value = u> 
<id type/subtype='Call status', value='CS screening connect' > 



PP opens speaker, and 
mutes the microphone 



Figure 80-8: Call screening acceptance 

7.4.36.6.4 Call screening rejection (PP to FP) 

The screened call can be rejected by the PP as follows: 

If the screened call is a first call, the PP shall reject it by sending a {CC-RELEASE-COM} message (abnormal 
release). 
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If the screened call is a parallel call, the PP shall reject it by using the call waiting rejection procedure (see 
clause 7.4.3.5.7). 

NOTE 1: Call screening rejection should be user initiated. A PP for which screening is not desired should be 
deactivated as described in clause 7.4.36.5.1.7. 

NOTE 2: if the screened call (first of parallel) is rejected by a PP, call screening presentation continues with other 
PPs. 

See figure 80-9 below for an example. 



PP 



FP 



Call screening indication 
CC-INFO 



« CALL-INFORMATION, 
<id type/subtype = 'Call identifier', value=01 H> 
<id type/subtype='line id/external call', value = u> 
<id type/subtype = 'Call status', value='CS screening setup' > 



First screened call rejection 

CC-RELEASE-COM 



Parallel screened call rejection 

CC-INFO 



« MULTI-KEYPAD, info = '1C 36'H » 



7.4.36.6.5 



Figure 80-9: Call screening rejection 



Call screening interception (PP to FP) 



Call screening interception allows the PP to pick up a screened call as a regular incoming call (instead of as a screened 
call). When a screened call is intercepted, screening of the call and DTAM recording both stop. 

Call screening interception shall only be used after a call screening acceptance by the same PP (i.e. after control code 
1C48H has been sent by this PP). 

See figure 80-10 below for an example. 



£75/ 



160 



ETSI TS 102 527-5 VI. 1.1 (2013-04) 



Screening PP 

I 

User presses on talk 
key to intercept the call 



Call screening interception 
CC-INFO 



« MULTI-KEYPAD, <Keypad info = 1C49H > » 
« CALL-INFORMATION, 
<id type/subtype='Call identifier', value = 01H > 
» 

CC-INFO 



« CALL-INFORMATION, 
<id type/subtype='Call identifier', value = 01 H > 
<id type/subtype='line id/external call', value = u> 
<id type/subtype='Call status', value='CS call connect' > 



FP 



Figure 80-10: Call screening interception 

7.4.36.6.6 FP initiated call screening release (FP to PP) 

The FP shall use the FP initiated call screening release procedure in the following cases: 

None of the screening PPs accepted the call, i.e. all screening PPs either rejected or ignored the screened call 
within the screening acceptance timeout (see clause 7.4.36.5.1.7, field 'Screening parameters'). 

NOTE: In this case, the FP continues recording the DTAM incoming message as if no screening had been started. 

The remote user of the call hanged up the call. 

DTAM recording timer expired (which also terminates the call with the remote user). 
See figure 80-1 1 below for an example. 



PP 



FP 

I 

None of the screening PPs 
accepted the call within 
timer 



First screened call release 

CC-RELEASE 



Parallel screened call release 

CC-INFO 



« CALL INFORMATION, call status = CS idle » 



Figure 80-11 : Call screening release (example) 
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7.4.36.6.7 Parallel call during active call screening 

See table 75-72 below. 

Table 75-72: Supported parallel call procedure during active call screening 



Procedure name 


PP 
Support 


FP 
Support 


Outgoing parallel call initiation (external or internal) 








Call waiting indication (external or internal) 


M 


M 


Call waiting acceptance 


M 


M 


Call waiting rejection 


M 


M 


Active call release with replacement (from PP to FP) 


M 


M 


Call toggle request (external or internal) 


M 


M 


Negative acknowledgement 


M 


M 


Putting a call on-hold 


M 


M 


Resuming a call put on-hold 


M 


M 


Intrusion call request indication (only internal) 








3-party conference call request (external or internal) 








Call transfer request (external or internal) 








Explicit call intrusion 









7.4.36.6.8 Call screening of a waiting call 

The FP may indicate call screening to the PP after a call waiting indication. As for a first screened call, the user may: 

accept the screened call with a call screening acceptance (1C48H; see figure 80-12 below); 

reject the screened call with a regular call waiting rejection (1C36H) as defined in clauses 7.4.3.5.7 and 
7.4.36.6.4; 

pick it up as a regular waiting call with a call waiting acceptance (1C35H), or an active call release with 
replacement (1C38H). If the call is picked up, DTAM recording and screening both stop; 

ignore the screened call (in which case clause 7.4.36.6.6 applies). 
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PP 



FP 




Ongoing internal or external call, call id = 1 




Call waiting indication 

CC-INFO 



If required by the "Tones 
provision' feature 

Line on which waiting call 
occurred if external 



CW tone 
heard by user 



« SIGNAL value = 'call waiting tone' = '07'H » 

I « CALL-INFORMATION, 

< id type/subtype = 'Line id/external call', value = 'waiting call line id' > 

< id type/subtype = 'Line id/line type info', value = 'xy'B> 

< id type/subtype = 'Call identifier', value = 'waiting call id' = '02'H >, 

< id type/subtype = 'Call status', value = 'CS call setup' > 

> 

CC-INFO 



« CALLING PARTY NUMBER, < Calling Party Address = 'calling number' > » 
« CALL-INFORMATION call id = waiting call id = 2 » 



FP starts playing of Welcome 
message towards remote user 



Call screening indication 
CC-INFO 



« CALL-INFORMATION, call id=2, line id=u, call status=CS screening setup » 

Call screening acceptance 
CC-INFO 



« MULTI-KEYPAD, <Keypad info = 1C48H > » 
« CALL-INFORMATION call id=2 » 

CC-INFO 



: CALL-INFO call id=1 , call status='CS call hold' » 



CC-INFO 



;< CALL-INFORMATION call id=2, call status='CS screening connect' » 



7.4.36.6.9 



Figure 80-12: Waiting call screening 



Call screening with screening and non-screening PPs 



The present clause describes call screening in a multiple PP environment and applies to a DECT system containing the 
following: 

A DTAM-supporting FP, connected to a local or remote DTAM. 

Screening PPs and non-screening PPs. 

When screening of the external incoming call starts, the call shall be released by the FP for all non-screening PPs. 

When screening is accepted by one of the PPs, and if the FP is in single screened call mode, the FP shall release the call 
for all other (screening) PPs. 

See figure 80-13 below for an example. 
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Non- 
screening 
PP 



Screening 
PP2 



Screening 
PP1 



FP 



CC-SETUP 



«CALL-INFO call id=01H, line id=u, call status='CS call setup'» 
CC-SETUP 



«CALL-INFO call id=01H, line id=u, call status='CS call setup'» 
CC-SETUP 



«CALL-INFO call id=01H, line id=u, call status='CS call setup'» 
CC-ALERTING 



«CALL-INFORI\/IATION call id=1» 

CC-ALERTING 



«CALL-INFORIVIATION call id=1» 

CC-ALERTING 



«CALL-INFORI\/IATION call id=1» 



FP starts playing of Welcome 
message towards remote user 



Call screening indication or release 
CC-INFO 



«CALL-INFORIVIATION call id=1Jine id=u, 

call status=CS screening setup» 

CC-INFO 



«CALL-INFORMATiON call id=1,line id=u, 

call status=CS screening setup» 

CC-RELEASE 



DTAM incoming call 
automatically accepted 



Call screening acceptance 

CC-INFO 



« IVIULTI-KEYPAD keypad info =» 
«CALL-INFORI\/IATION call id=1» 

CC-CONNECT 



«CALL-INFORIVIATION call id=1» 



CC-CONNECT-ACK 



«CALL-INFORMATION call id=1» 
CC-RELEASE 



If FP only supports 
single PP call screening 



CC-INFO 



«CALL-INFORMATION call id=1,line id=u, 

call status=CS screening connect» 



PP opens speaker, and 
mutes the microphone 

I 



Figure 80-13: Call screening with screening and non-screening PPs 
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7.4.36.6.10 



Single/Multiple PP(s) call screening mode 



Single PP call screening mode. If a FP only supports a single PP in screening mode, or if the FP is configured in single 
PP screening mode, and as soon as one of the screening PPs accepts the screened call, the FP shall release the screened 
call for all other PPs by using the 'FP initiated call screening release' procedure (see clause 7.4.36.6.6). 

Multiple PPs call screening mode. In the case where one of the screening PPs accepts the received call screening 
indication, the screened call presentation continues for all other screening PPs, and can still be accepted by them. 

See the following figure 80-14 for an example. 



Screening 
PP2 



Screening 
PP1 



FP 



CC-SETUP 



«CALL-INFO call id=01H, line id=u, call status='CS call setup'» 
CC-SETUP 



«CALL-INFO call id=01H, line id=u, call status='CS call setup'» 
CC-ALERTING 



«CALL-INFORMATION call id=1» 

CC-ALERTING 



cCALL-INFORMATION call id=1: 



FP starts playing of Welcome 
message towards remote user 



Call screening indication 
CC-INFO 



«CALL-INFO call id=1 ,line id=u, call status=CS screening setup(>: 

CC-INFO 



«CALL-INFO call id=1 ,line id=u, call status=CS screening setup 

DTAM incoming call accepted by both PPs 

CC-INFO 



« MULTI-KEYPAD keypad info = 1C48H » 
«CALL-INFORMATION call id=1» 
CC-INFO 



« IVIULTI-KEYPAD keypad info = 1C48H » 
«CALL-INFORIViATION call id=1» 

CC-CONNECT 



«CALL-INFORIVIATION call id=1» 
CC-CONNECT 



«CALL-INFORMATION call id=1» 
CC-CONNECT-ACK 



«CALL-INFORI\/IATION call id=1» 
CC-CONNECT-ACK 



«CALL-INFORI\/IATION call id=1» 
CC-INFO 



«CALL-INFO call id=1,line id=u, call status=CS screening conn|ect» 
CC-INFO 



«CALL-INFO call id=1 ,line id=u, call status=CS screening conr ect» 



Both PPs opens speaker, and 
mutes the microphone 



Figure 80-14: Call screening acceptance by multiple PPs 
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7.5 Data Link Control (DLC) layer procedures 

All mandatory requirements as defined in clause 7.5 of TS 102 527-3 [18] shall apply. 

7.6 Medium Access Control (IVIAC) layer procedures 

All mandatory requirements as defined in clause 7.6 of TS 102 527-3 [18] shall apply. 

7.7 Physical layer (PHL) requirements 

All mandatory requirements as defined in clause 7.7 of TS 102 527-3 [18] shall apply. 

7.8 Requirements regarding the speech transmission 

All mandatory requirements as defined in clause 7.8 of TS 102 527-3 [18] shall apply. 

7.9 IVIanagement procedures 

All procedures described in GAP (EN 300 444 [11], clause 13) shall be supported. Higher layer capability FP broadcast 
shall be set as described in clause 7.4.9.2 of the present document. 

7.10 Application procedures 

7.10.1 Easy PIN code and easy pairing registration 

All mandatory requirements as defined in clause 7.10.1 of TS 102 527-3 [18] shall apply. 

7.10.2 Handset locator 

All mandatory requirements as defined in clause 7.10.2 of TS 102 527-3 [18] shall apply. 

7. 1 0.3 Transmit power control 

7.1 0.3.1 Base manual transmit power control 

Feature content will be provided in a further revision of the present document. 

7.1 0.3.2 Handset adaptive transmit power control 

Feature content will be provided in a further revision of the present document. 
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Annex A (normative): 
System parameters 

A.1 CC timers 

All mandatory requirements as defined in clause A. 1 of TS 102 527-3 [18] shall apply with the following additions: 

<CC.NG.02> Notification allowed deferring timer. 

FT value: 2 000 milliseconds. 

PT value: Not used. 

Start: End of session (case 1), End of call (case 2), Event time (case 3). 

Stop: none. 

NOTE 1: The 3 uses of the timer and corresponding start times are described in clause 7.4.10.9.2.2. 

<CC.NG.03> SMS Sending to network timer. 

FT value: 2 000 milliseconds. 

PT value: Not used. 

Start: Arrival of SMS in Outgoing SMS List. 

Stop: SMS handed over to network (and moved to the Sent SMS List). 

NOTE 2: If timeout is reached, entry addition in the Outgoing SMS List is notified to the PP. The FP may still try 
to hand over SMS to the network after timeout. If it succeeds after timeout, entry deletion from the 
Outgoing SMS List is also notified to the PP. 

A.2 IVIIVI timers 

All mandatory requirements as defined in clause A.2 of TS 102 527-3 [18] shall apply. 

A.3 Application timers 

All mandatory requirements as defined in clause A.3 of TS 102 527-3 [18] shall apply. 



A.4 Constants 



PI 00: FP side maximum response time allowed for an Li A command (as a complete exchange) when the answer fits in 
a single data packet last. 

The mandated value is 800 milli-seconds. 
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Annex B (normative): 
Procedure Diagrams 

For the purposes of the present document, the diagrams in TS 102 527-3 [18], annex B shall apply. 
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Annex C (informative): 

Recommended implementation of procedures 

For the purposes of the present document, the recommendations in TS 102 527-3 [18], annex C apply. 
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Annex D (informative): 

Guidelines for implementation of DTMF 

For the purposes of the present document, the guidelines in TS 102 527-3 [18], annex D apply. 
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Annex E (informative): 

Tones format in Recommendations ITU-T 

For the purposes of the present document, the recommendations in TS 102 527-3 [18], annex E apply. 
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Annex F (informative): 

Services and features defined in other specifications 

F.1 Services and features defined in TS 102 527-1 (New 
Generation DECT; part 1) 

The following informative annex shows the features and services defined in TS 102 527-1 [17] (New Generation 
DECT; part 1), many of them are reused in the present document. This list is informative, and shows the status in 
TS 102 527-1 [17] (VI. 2.1). Where there are changes or divergences the original definitions at TS 102 527-1 [17] 
apply. 

F.I .1 New Generation DECT; part 1 , Speech Services (clause 5.1 
ofTS 102 527-1) 

Narrow band ADPCM G.726 voice service [NGl.l]: Recommendation ITU-T G.726 [12] narrow band codec 
[NGl.SC.l] over 32 kbit/s unprotected transmission channel. 

Narrow band PCM G.711 voice service [NG1.2]: Recommendation ITU-T G.71 1 [13] narrow band codec 
[NG1.SC.2] over 64 kbit/s protected or unprotected transmission channels. 

Wideband 7 kHz G.722 voice service [NG1.3]: Recommendation ITU-T G.722 [14] wideband codec [NG1.SC.3] 
over 64 kbit/s protected or unprotected transmission channels. 

Wideband 7 kHz low rate G.729.1 voice service [NG1.4]: Recommendation ITU-T G. 729.1 [15] wideband codec 
[NG1.SC.4] over 32 kbit/s unprotected transmission channels. 

Super wideband 14 kHz MPEG-4 ER AAC-LD voice service [NG1.5]: MPEG-4 ER AAC-LD super wideband 
codec [NG1.SC.5] over 64 kbit/s protected or unprotected transmission channels. 

Wideband 11 kHz low rate MPEG-4 ER AAC-LD voice service [NG1.6]: MPEG-4 ER AAC-LD super wideband 
codec [NG1.SC.6] over 32 kbit/s unprotected transmission channels. 

F.I .2 New Generation DECT; part 1 , Network (NWK) features 
(clause 5.2 of TS 102 527-1) 

Codec Negotiation [NGl.N.l): capability to negotiate the speech codec to be used in a communication, based on the 
supported capabilities in both peers and the previsions included in the present document. This feature may require slot 
type change. 

Codec Switching [NG1.N.2): capability to switch between different speech codecs during a call. This feature may 
require slot type change. 

F.I .3 New Generation DECT; part 1 , Data Link Control (DLC) 
services (clause 5.3 of TS 102 527-1) 

LUl Transparent Unprotected service (TRUP) Class 0/minimum_delay [NGl.D.l]: transparent unprotected 

service introducing minimum delay, transmission Class 0/min_delay as defined by EN 300 175-4 [4], clause 1 1.2. 

LUl Transparent Unprotected service (TRUP) Class [NG1.D.2]: transparent unprotected service introducing 

minimum delay, transmission Class as defined by EN 300 175-4 [4], clause 1 1.2. 

LU7 64 kbit/s protected bearer service [NG1.D.3]: protected service providing reliable 64 kbit/s transmission over 
packet type P80 incorporating EEC and ARQ protection mechanisms. Defined by EN 300 175-4 [4], clause 1 1.9. 
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LU12 UNProtected Framed service (UNF) Class [NG1.D4]: unprotected service introducing normal delay, 

transmission Class as defined by EN 300 175-4 [4], clause 11. 14. 

FUl DLC frame [NG1.D.5]: bidirectional frame used in LUl service. Defined in EN 300 175-4 [4], clause 12.2. 
Frame length depends on slot type and is defined in table 12.2.1.1 of EN 300 175-4 [4], clause 12.2.1. 

FU7 DLC frame [NG1.D.6]: bidirectional frame used in LU7 service. Defined in EN 300 175-4 [4], clause 1 1.9. 

FU12 DLC frame with adaptation for codec G.729.1 [NG1.D.7]: bidirectional frame used in LU12 service, as 
defined in EN 300 175-4 [4], clause 12.12, frame size specified for full slot, 2-level modulation and with the adaptation 
for codec G.729.1 defined in EN 300 175-4 [4], clause E.l. 

F.1 .4 New Generation DECT; part 1 , Medium Access Control 
(IVIAC) services (clause 5.4 of TS 1 02 527-1 ) 

lN_minimum delay symmetric MAC service type [NGl.M.l]: lN_minimum delay symmetric connection as defined 

in EN 300 175-3 [3], clause 5.6.2.1. 

lN_normal delay symmetric MAC service type [NG1.M.2]: lN_normal delay symmetric connection as defined in 

EN 300 175-3 [3], clause 5.6.2.1. 

IpQ_error_detection symmetric MAC service type [NG1.M.3]: Ipq_ error_detection symmetric connection as defined 
in EN 300 175-3 [3], clause 5.6.2.1. (type 3: Ip_ error_detection with single-subfield protected B-field as defined in 
EN 300 175-3 [3], clause 6.2.1.3.4). 

Advanced Connections [NG1.M.4]: MAC Connection Oriented service providing connection between FT and PT. 
Advanced connections are able to support multiple bearers, bearers different of the full slot, and any MAC service. The 
service includes the means for setting-up and releasing the required bearer(s). 

F.1 .5 New Generation DECT; part 1 , Physical Layer (PHL) 
services (clause 5.5 of TS 102 527-1) 

2 level GFSK modulation [NGl.P.l]: 2 level Gaussian frequency Shift Key (GFSK) modulation as defined by 

EN 300 175-2 [2], clause 5. 

Physical Packet P32 [NG1.P.2]: physical packet P32 (full slot) as defined by EN 300 175-2 [2], clause 4.4.2. 

Physical Packet P64 [NG1.P.3]: variable capacity Physical packet POOj as defined by EN 300 175-2 [2], clause 4.4.3, 
withj =640. 

Physical Packet P67 [NG1.P.4]: variable capacity Physical packet POOj as defined by EN 300 175-2 [2], clause 4.4.3, 
with j = 672. 

Physical Packet P80 [NG1.P.5]: physical packet P80 (double slot) as defined by EN 300 175-2 [2], clause 4.4.4. 

F.1 .6 New Generation DECT; part 1 , Speech coding and audio 
features (clause 5.6 of TS 102 527-1) 

G.726 32 kbit/s ADPCM [NGl.SC.l]: Recommendation ITU-T G.726 [12] narrow band codec as defined by 

EN 300 175-8 [8], clause 5.1. Recommendation ITU-T G.726 [12] codec is mandatory for New Generation DECT in 

order to ensure interoperability with existing DECT systems. 

G.711 64 kbit/s log-PCM [NG1.SC.2]: Recommendation ITU-T G.711 narrowband codec [13] as defined by 

EN 300 175-8 [8], clause 5.2. Recommendation ITU-T G.711 [13] codec is optional for New Generation DECT in order 

to improve the quality of narrow band communications, and fax/modem transmissions. 

Recommendation ITU-T G.711 [13] provides a slightly higher intrinsic voice quality and no transcoding for PSTN 

calls. Both, A-Law and |j,-Law are supported. 
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G.722 64 kbit/s wideband [NG1.SC.3]: Recommendation ITU-T G.722 wideband SB-ADPCM 7 kHz codec [14] as 
defined by EN 300 175-8 [8], clause 5.3. Recommendation ITU-T G.722 [14] is chosen as mandatory wideband codec 
for New Generation DECT in order to greatly increase the voice quality by extending the bandwidth from narrow band 
to wideband. Recommendation ITU-T G.722 [14] provides a high wideband quality at a bit rate of 64 kbit/s with low 
complexity and very low delay. 

G.729.1 32 kbit/s wideband [NG1.SC.4]: Recommendation ITU-T G.729.1 wideband codec [15] as defined by 
EN 300 175-8 [8], clause 5.4. Recommendation ITU-T G.729.1 [15] codec is optional for New Generation DECT in 
order to provide even higher wideband quality and better robustness to packets/frames losses than 
Recommendation ITU-T G.722 [14] at half the bit rate of Recommendation ITU-T G.722 [14]. This allows a better 
transport efficiency on the network side and over the DECT air interface (one full slot). In addition, it is seamless 
interoperable with largely deployed Recommendation ITU-T G.729 [i.7] based VoIP networks and terminals. 
Recommendation ITU-T G.729.1 [15] encodes signals in frames of 20 ms. It is a scalable codec operating at bitrates of 
8 kbit/s and from 12 kbit/s to 32 kbit/s per steps of 2 kbit/s, in narrow band or in wideband from 14 kbit/s. 
Recommendation ITU-T G.729.1 [15] already incorporates a high efficiency packet loss concealment mechanism. 

MPEG-4 ER AAC-LD 64 kbit/s super wideband [NG1.SC.5]: MPEG-4 ER AAC-LD codec as defined by 
ISO/IEC 14496-3:2009: [16] and by EN 300 175-8 [8] clause 5.5. 1. MPEG-4 ER AAC-LD is optional for New 
Generation DECT in order to provide higher quality than G.722 by further extending the bandwidth to superwideband 
(50 Hz to 14 kHz) (and even further, up to full audio bandwidth (20 Hz to 20 kHz)). MPEG-4 ER AAC-LD is designed 
for high quality communication applications including all kind of audio signals e.g. speech and music and provides a 
high quality for music streaming or other multimedia applications mixing speech and music. It provides an audio 
bandwidth of 14 kHz or more at a bitrate of 64 kbit/s. MPEG 4 ER AAC-LD (Error resilient. Low Delay AAC profile) 
is standardized as an audio profile of MPEG-4 (ISO/lEC 14496-3 [16]). The frame size is 10 ms and the algorithmic 
delay 20 ms. 

MPEG-4 ER AAC-LD 32 kbit/s wideband [NG1.SC.6]: as [NG1.SC5], but using the 32 kbit/s mode, as defined by 
EN 300 175-8 [8], clause 5.5.2. It provides a bandwidth of 1 1,5 kHz or more. The frame size is 20 ms and the 
algorithmic delay 40 ms. 

PLC (Packet Loss Concealment) G.722 Appendix III & IV [NG1.SC.7]: to better cope with transmission errors, a 
Packet Loss Concealment algorithm (PLC) as defined by EN 300 175-8 [8], clause 5.3.2 may be optionally 
implemented for Recommendation ITU-T G.722 [14]. Appendices III and IV describe packet loss concealment 
solutions extending the Recommendation ITU-T G.722 [14] decoder. These PLC algorithms may be optionally 
implemented to improve voice quality in degraded transmission conditions where packets/frames may be lost (in IP 
network or on DECT air interface). 

NOTE 1 : Both appendices meet the same quality requirements but address two different quality/complexity trade 
offs: 

1) Appendix III aims at maximizing the robustness at a price of additional complexity. 

2) Appendix IV proposes an optimized complexity/quality trade off with almost no additional 
complexity compared with Recommendation ITU-T G.722 [14] normal decoding (0,07 WMOPS). 

Since Recommendation ITU-T G.722 [14] does not incorporate any mechanism to cope with lost frames/packets, the 
use of a PLC algorithm is strongly recommended to avoid annoying effects of packet/frame losses. 

NOTE 2: Recommendation ITU-T G.729.1 [15] already incorporates a packet loss concealment mechanism. 

Detection of Modem/fax tone [NG1.SC.8]: detection of the 1 100 Hz, 1 300 Hz and 2 100 Hz standard tones 
indicating a fax/modem transmission and answering, as defined by EN 300 175-8 [8] clause 5.2.2. The main utility of 
this function is the switching of codecs to transparent PCM (Recommendation ITU-T G.71 1 [13]) in order to facilitate 
modem/fax transmission. The tone detection can also be used to de-activate echo suppression if present. 

Codec selection and switching [NG1.SC.9]: to handle several codecs (at least Recommendation ITU-T G.726 [12] and 
Recommendation ITU-T G.722 [14]), New Generation DECT will support a codec selection and switching mechanism. 
This may consequently allow the use of other codecs that could be specified in next releases as additional optional 
codecs according to future application or interoperability needs. 

PP Audio type la ("classic GAP" handset) [NGl.SC.lO]: Audio specification for a general purpose 3,1 kHz 
telephony handset as defined by EN 300 175-8 [8], clause 7.2.3. 
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PP audio type lb ("improved GAP" handset) [NGl.SC.ll]: Audio specification for a general purpose 3,1 kHz 
telephony handset with improved TCLw, as defined by EN 300 175-8 [8], clause 7.2.4. It is compatible with VoIP and 
long delay networks. 

PP audio type Ic (HATS tested, 3,1 kHz handset) [NG1.SC.12]: Audio specification for a general purpose 3,1 kHz 
telephony handset based on the new HATS methodology, as defined by EN 300 175-8 [8], clause 7.2.5. It includes 
strong echo suppression (TCLw) requirements and is compatible with VoIP and long delay networks. 

PP audio type Id (HATS tested, 3,1 kHz "improved" handset) [NG1.SC.13]: Audio specification for a general 
purpose 3,1 kHz telephony handset based on the new HATS methodology with improved quality, as defined by 
EN 300 175-8 [8], clause 7.2.6. It includes strong echo suppression (TCLw) requirements and is compatible with VoIP 
and long delay networks. This type has a more demanding acoustic specification, providing superior subjective quality. 
In practice, this means better electro-acoustic components (speaker, microphone), electronics and signal processing. 

PP Audio type 2a (Recommendation ITU-T P.311 7 kHz handset) [NG1.SC.14]: Audio specification for a 
wideband, 7 kHz service, handset based on the Recommendation ITU-T P. 31 1 [i.6], as defined by EN 300 175-8 [8], 
clause 7.2.9. 

PP Audio type 2b (HATS 7 kHz handset) [NG1.SC.15]: Handset for 7 kHz service (wideband), based on HATS 
methodology, as defined by EN 300 175-8 [8], clause 7.2. 10. It includes strong echo suppression (TCLw) requirements 
and is compatible with VoIP and long delay networks. 

PP Audio type 2c (HATS 7 kHz "improved" handset) [NG1.SC.16]: Handset for 7 kHz service (wideband), based 
on HATS methodology, with improved quality, as defined by EN 300 175-8 [8], clause 7.2.11. It includes strong echo 
suppression (TCLw) requirements and is compatible with VoIP and long delay networks. This type has a more 
demanding acoustic specification, providing superior subjective quality. In practice, this means better electro-acoustic 
components (speaker, microphone), electronics and signal processing. 

PP audio type 3a (HATS tested, 3,1 kHz handsfree) [NG1.SC.17]: Audio specification for a Narrowband (3,1 kHz) 
handsfree device as defined by EN 300 175-8 [8], clause 7.2.7. This type applies to handsfree devices operating with an 
open loudspeaker and microphone. The type applies to either: 

1) specific PPs designed to operate in handsfree mode; 

2) standard handset implementing types la, lb, Ic or Id, but with the option to operate in handsfree mode; and 

3) handsfree accessory devices connected to a handset by any wired or wireless technology. 

It provides (300 Hz - 3,4 kHz) frequency range, and it is defined based on HATS methodology. 

PP audio type 3b (HATS tested, 3,1 kHz "improved" handsfree) [NG1.SC.18]: Audio specification for a 
Narrowband (3,1 kHz) handsfree device, improved quality version, as defined by EN 300 175-8 [8], clause 7.2.8. This 
type applies to handsfree devices operating with an open loudspeaker and microphone. The type applies to either: 

1) specific PPs designed to operate in handsfree mode; 

2) standard handset implementing types la, lb, Ic or Id, but with the option to operate in handsfree mode; and 

3) handsfree accessory devices connected to a handset by any wired or wireless technology. 

It provides (300 Hz - 3,4 kHz) frequency range, and it is defined based on HATS methodology. This type has a more 
demanding acoustic specification, providing superior subjective quality. In practice, this means better electro-acoustic 
components (speaker, microphone), electronics and signal processing. 

PP Audio type 4a (HATS 7 kHz handsfree) [NG1.SC.19]: Wideband (7 kHz) handsfree device, as defined by 
EN 300 175-8 [8], clause 7.2.12. This type applies to handsfree devices operating with an open loudspeaker and 
microphone. The profile applies to either: 

1) specific PPs designed to operate in handsfree mode; 

2) standard wideband handset implementing profiles 2a, 2b or 2c, but with the option to operate in handsfree 
mode; and 

3) handsfree accessory devices connected to a handset by any wired or wireless technology. 
It provides (150 Hz - 7 kHz) frequency range, and it is defined based on HATS methodology. 
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PP Audio type 4b (HATS 7 kHz "improved" handsfree) [NG1.SC.20]: Wideband (7 kHz) handsfree device, 
improved quality version, as defined by EN 300 175-8 [8], clause 7.2.13. This type applies to handsfree devices 
operating with an open loudspeaker and microphone. The profile applies to either: 

1) specific PPs designed to operate in handsfree mode; 

2) standard wideband handset implementing profiles 2a, 2b or 2c, but with the option to operate in handsfree 
mode; and 

3) handsfree accessory devices connected to a handset by any wired or wireless technology. 

It provides (150 Hz - 7 kHz) frequency range, and it is defined based on HATS methodology. This type has a more 
demanding acoustic specification, providing superior subjective quality. In practice, this means better electro-acoustic 
components (speaker, microphone), electronics and signal processing. 

PP Audio type 5a (Super wideband 14 kHz) [NG1.SC.21]: Handset for 14 kHz service (super wideband), as defined 

by EN 300 175-8 [8], clause 7.2.14. 

PP Audio type 5b (Super wideband 14 kHz, handsfree) [NG1.SC.22]: Handsfree device for 14 kHz service (super 
wideband), as defined by EN 300 175-8 [8], clause 7.2.15. 

FP audio type lb ("new ISDN" 3,1 kHz) [NG1.SC.23]: Audio specification for a DECT FP supporting narrowband 
service and providing a digital 64 kbit/s G.71 1 interface, typically (but not necessarily) an ISDN connection, new 
specification, as defined by EN 300 175-8 [8], clause 7.3.3. 

NOTE 3: FP Audio type la ("classic ISDN", 3,1 kHz FP, see EN 300 175-8 [8]) is not to be used in in New 

Generation DECT equipment. Instead of it, FP type lb should be used in NG-DECT FPs with ISDN or 
digital circuit-switch interfaces. 

PP echo canceller for FP, narrowband (3,1 kHz) service [NG1.SC.24]: Auxiliary feature for FPs consisting on echo 
canceller for handling the echo generated by PPs type la. As defined by EN 300 175-8 [8], clause 7.4.2. Only 
narrowband echo cancellation capability is required for this feature. 

PP echo supressor for FP, narrowband (3,1 kHz) service [NG1.SC.25]: Auxiliary feature for FPs consisting on echo 
supressor for handling the echo generated by PPs type la. As defined by EN 300 175-8 [8], clause 7.4.3. Only 
narrowband capability is required for this feature. 

FP audio type 2 (analog PSTN 3,1 kHz) [NG1.SC.26]: Audio specification for a DECT FP supporting narrowband 
service and providing an analog 2-wire PSTN interface. As defined by EN 300 175-8 [8], clause 7.3.4. 

FP audio type 3 (VoIP 3,1 kHz) [NG1.SC.27]: Audio specification for a DECT FP supporting narrowband service and 
providing a VoIP interface, with codecs G.71 1 (typically) or G.726 on top of it. As defined by EN 300 175-8 [8], 
clause 7.3.5. 

FP Audio type 4 (ISDN, wideband) [NG1.SC.28]: Audio specification for a DECT FP supporting wideband service 
and providing a digital 64 kbit/s interface, typically (but not necessarily) an ISDN connection, with a wideband codec 
such as G.722, MPEG, etc. As defined by EN 300 175-8 [8], clause 7.3.6. 

FP Audio type 5 (VoIP wideband) [NG1.SC.29]: Audio specification for a DECT FP supporting wideband service 
and providing a VoIP interface, with a wideband codec on top such as G.722, MPEG, etc. As defined by 
EN 300 175-8 [8], clause 7.3.8. 

PP echo canceller for FP, wideband (7 kHz) service [NG1.SC.30]: Auxiliary feature for FPs consisting on echo 
canceller for handling the echo generated by PPs type 2a. As defined by EN 300 175-8 [8], clause 7.4.2. Only wideband 
echo cancellation capability is required for this feature. 

PP echo supressor for FP, wideband (7 kHz) service [NG1.SC.31]: Auxiliary feature for FPs consisting on echo 
supressor for handling the echo generated by PPs type 2a. As defined by EN 300 175-8 [8], clause 7.4.3. Only wideband 
echo cancelation capability is required for this feature. 

FP audio type 6a (internal call) [NG1.SC.32]: This type of audio specification applies to the case of internal call 
inside a DECT FP or a DECT system without any external interface. FP audio type 6a is defined by EN 300 175-8 [8], 
clause 7.3.8. 
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FP audio type 6b (internal conference) [NG1.SC.33]: This type of audio specification applies to the case of 3-party 
or muhi-party conference inside a DECT FP or a DECT system with or without an external interface. FP audio type 6b 
is defined by EN 300 175-8 [8], clause 7.3.9. 

Adaptive volume control for FP [NG1.SC.34]: Accessory feature for FPs consisting on an adaptive volume control 
depending on the level of environmental noise at the PP. The gain variation is symmetrical. As described in 
EN 300 175-8 [8], clause 7.6 and informative annex D. 



F.2 Services and features defined in EN 300 444 (GAP) 

The following informative annex shows the features and MAC/DLC services defined in EN 300 444 [11] (GAP), many 
of them are reused in the present document. This list is informative, and shows the status in EN 300 444 [11]. Where 
there are changes or divergences the original definitions at EN 300 444 [11] (GAP) apply. 

F.2.1 GAP Network (NWK) features (clause 4.1 of EN 300 444) 

outgoing call [N.l]: call initiated at a DECT PP. 

off-hook [N.2]: ability to indicate the action of going off-hook, e.g. to start call setup or accept a call. 

on-hook (FULL Release) [N.3]: ability to indicate the action of going on-hook (e.g. to terminate a call) and fully 
release the radio resource. 

dialled digits (basic) [N.4]: capabiUty to dial digits to 9, *, #. 

register recall [N.5]: ability of the PP to request the invocation of the supplementary service "register recall" over the 
DECT interface and the ability of the FP to transmit the request to the local network. Register recall means to seize a 
register (with dial tone) to permit input of further digits or other action. 

go to DTMF signalling (defined tone length) [N.6]: go to DTMF signalling with defined tone length. 

pause (dialling pause) [N.7]: ability to generate or indicate a dialling pause, e.g. to await further dial tone. 

incoming call [N.8]: call received at a DECT PP. 

authentication of PP [N.9]: process by which the identity of a DECT PP is checked by the FP. 

authentication of user [N.IO]: process by which the identity of a user of a DECT PP is checked by the FP. The User 
Personal Identification (UPI), a personal identification of to 8 digits, manually entered by the user, is used for user 
authentication. 

location registration [N.ll]: facility whereby a PP can be registered with a FP or a cluster of FPs such that incoming 
calls, radio pages or messages may be routed to it. 

on-air key allocation [N.12]: capability to transform Authentication Code (AC) into User Authentication Key (UAK) 
using the key allocation procedure. 

identification of PP [N.13]: ability for the FP to request and PP to provide specific identification parameters. 

service class indication/assignment [N.14]: assignment by the FP to PP of the service class and indication to the FP by 
the PP of the contents of its service class. 

alerting [N.15]: activates or deactivates alerting at the PP using any appropriate indication. 

ZAP [N.16]: ability first to assign and then to re-program the account data held in the PP so that access rights may be 
suspended subject to the conditions set by the service provider being met, coupled with the ability to re-program the 
account data again to reinstate access rights once these conditions have been met. One ZAP field should be provided per 
account field. The PP has the right to authenticate the FP prior to the execution of ZAP suspend. 

encryption activation FT initiated [N.17]: activation of the encryption process requested by FT. 

subscription registration procedure on-air [N.18]: standardized procedure for loading subscription registration data 
into a PP in real time over the air-interface. 
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link control [N.19]: ability to request, accept, maintain and release a data link for the purposes of a NWK layer 
procedure. 

terminate access rights FT initiated [N.20]: ability of the FP to delete a subscription in the PP. 

partial release [N.21]: ability to release an established or in progress Call Control (CC) call whilst retaining the radio 
resource for the purpose of accessing further services. 

go to DTMF (infinite tone length) [N.22]: go to DTMF signalling, indicating infinite DTMF tone duration. 

go to pulse [N.23]: go to pulse (decadic) signalling. 

signalling of display characters [N.24]: transmission to the PP of characters to be displayed on the user's PP display 
(if provided). 

display control characters [N.25]: characters sent to the PP to control the user's display in the PP (if provided). Such 
characters include cursor control, clear screen, home, flash, inverse video, etc. 

authentication of FT [N.26]: process by which the identity of a FP is checked by the PP. 

encryption activation PT initiated [N.27]: activation of the encryption process suggested by PT. The real time start of 
ciphering is done in the MAC layer and is always initiated by the PT. 

encryption deactivation FT initiated [N.28]: deactivation of the encryption process requested by FT. The real time 
stop of ciphering is done in the MAC layer and is always initiated by the PT. 

encryption deactivation PT initiated [N.29]: deactivation of the encryption process suggested by PT. The real time 
stop of ciphering is done in the MAC layer and is always initiated by the PT. 

Calling Line Identification Presentation (CLIP) [N.30]: ability to provide the calling party number to the called party 
before accepting the call. 

internal call [N.31]: call between 2 users that does not make use of the local network resources. This is typically useful 
in residential environments. 

service call [N.32]: call initiated by a DECT PT for entering of FT related service and adjustment procedures in a 
transparent way. After having sent the service call indication, the PT behaves according to the rules of a normal call. 

Enhanced U- plane connection [N.33]: ability of the FT to initiate connection of the U- plane during call 
establishment or release e.g. to facilitate the provision of in band tones or announcements. 

Calling Name Identification Presentation (CNIP) [N.34]: ability to provide the calling party name to the called party 
before accepting the call. 

Enhanced Security [N.35]: mechanism to enhance DECT security by introduction of early encryption and the 
possibility of re-keying during an ongoing call. 

AES/DSAA2 authentication [N.36]: authentication using the DECT Authentication Algorithm #2 (DSAA2), based on 
AES, and including type 2 (see EN 300 175-7 [7]) air i/f procedures. 

F.2.2 GAP Speech coding and audio features (clause 4.2 of 
EN 300 444) 

For the purposes of the present document the following definitions apply: 

G.726 32 kbit/s ADPCM [SCI]: Recommendation ITU-T G.726 [12] narrow band codec as defined by 
EN 300 175-8 [8] clause 5.1. 

PP audio type la ("classic GAP" handset) [SC.2]: audio specification for a general purpose 3,1 kHz telephony 
handset as defined by EN 300 175-8 [8], clause 7.2.3. 

PP audio type lb ("improved GAP" handset) [SC.3]: audio specification for a general purpose 3,1 kHz telephony 
handset with improved TCLw, as defined by EN 300 175-8 [8], clause 7.2.4. It is compatible with VoIP and long delay 
networks. 
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PP audio type Ic (HATS tested, 3,1 kHz handset) [SC.4]: audio specification for a general purpose 3,1 kHz 
telephony handset based on the new HATS methodology, as defined by EN 300 175-8 [8], clause 7.2.5. It includes 
strong echo suppression (TCLw) requirements and is compatible with VoIP and long delay networks. 

PP audio type Id (HATS tested, 3,1 kHz "improved" handset) [SC.5]: audio specification for a general purpose 
3,1 kHz telephony handset based on the new HATS methodology with improved quality, as defined by 
EN 300 175-8 [8], clause 7.2.6. It includes strong echo suppression (TCLw) requirements and is compatible with VoIP 
and long delay networks. This type has a more demanding acoustic specification, providing superior subjective quality. 
In practice, this means better electro-acoustic components (speaker, microphone), electronics and signal processing. 

PP audio type 3a (HATS tested, 3,1 kHz handsfree) [SC.6]: audio specification for a Narrowband (3,1 kHz) 
handsfree device as defined by EN 300 175-8 [8], clause 7.2.7. This type applies to handsfree devices operating with an 
open loudspeaker and microphone. The type applies to either: 

1) specific PPs designed to operate in handsfree mode; 

2) standard handset implementing types la, lb, Ic or Id, but with the option to operate in handsfree mode; and 

3) handsfree accessory devices connected to a handset by any wired or wireless technology. 

It provides (300 Hz to 3,4 kHz) frequency range, and it is defined based on HATS methodology. 

PP audio type 3b (HATS tested, 3,1 kHz "improved" handsfree) [SC.7]: audio specification for a Narrowband 
(3,1 kHz) handsfree device, improved quality version, as defined by EN 300 175-8 [8], clause 7.2.8. This type applies to 
handsfree devices operating with an open loudspeaker and microphone. The type applies to either: 

1) specific PPs designed to operate in handsfree mode; 

2) standard handset implementing types la, lb, Ic or Id, but with the option to operate in handsfree mode; and 

3) handsfree accessory devices connected to a handset by any wired or wireless technology. 

It provides (300 Hz to 3,4 kHz) frequency range, and it is defined based on HATS methodology. This type has a more 
demanding acoustic specification, providing superior subjective quality. In practice, this means better electro-acoustic 
components (speaker, microphone), electronics and signal processing. 

FP audio type la ("classic ISDN" 3,1 kHz) [SC.8]: audio specification for a DECT FP supporting narrowband service 
and providing a digital 64 kbit/s G.711 interface, typically (but not necessarily) an ISDN connection, classic 
specification, as defined by EN 300 175-8 [8], clause 7.3.2. It is recommended to use FP type lb instead of type la. 

FP audio type lb ("new ISDN" 3,1 kHz) [SC.9]: audio specification for a DECT FP supporting narrowband service 
and providing a digital 64 kbit/s G.71 1 interface, typically (but not necessarily) an ISDN connection, new specification, 
as defined by EN 300 175-8 [8], clause 7.3.3. It is recommended to use FP type lb instead of type la. 

PP echo canceller for FP [SC.IO]: auxiliary feature for FPs consisting on echo canceller for handling the echo 
generated by PPs type la. As defined by EN 300 175-8 [8], clause 7.4.2. Only narrowband echo cancellation capability 
is required. 

PP echo suppressor for FP [SC.ll]: auxiliary feature for FPs consisting on echo suppressor for handling the echo 
generated by PPs type la. As defined by EN 300 175-8 [8], clause 7.4.3. Only narrowband capability is required. 

FP audio type 2 (analogue PSTN 3,1 kHz) [SC.12]: audio specification for a DECT FP supporting narrowband 
service and providing an analogue 2-wire PSTN interface. As defined by EN 300 175-8 [8], clause 7.3.4. 

FP audio type 3 (VoIP 3,1 kHz) [SC.13]: audio specification for a DECT FP supporting narrowband service and 
providing a VoIP interface, with codecs G.71 1 (typically) or G.726 on top of it. As defined by EN 300 175-8 [8], 
clause 7.3.5. 

FP audio type 6a (internal call) [SC.14]: this type of audio specification applies to the case of internal call inside a 
DECT FP or a DECT system without any external interface. This type applies to any service. As defined by 

EN 300 175-8 [8], clause 7.3.8. 

FP audio type 6b (internal conference) [SC.15]: this type of audio specification applies to the case of 3-party or 
multi-party conference inside a DECT FP or a DECT system with or without an external interface. Applies to any 
service. As defined by EN 300 175-8 [8], clause 7.3.9. 
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Adaptive volume control for FP [SC.16]: accessory feature for FPs consisting on an adaptive volume control 
depending on the level of environmental noise at the PP. The gain variation should be symmetrical. As described in 
EN 300 175-8 [8], (detailed descriptions for each type of FP in clause 7.6, and examples of settings in informative 
annex D). 

F.2.3 GAP Application features (clause 4.3 of EN 300 444) 

AC to bitstring mapping [A.l]: mapping of the AC into a bitstring. 

multiple subscription registration [A.2]: ability of PP to store more than one subscription. 

manual entry of the Portable Access Rights Key (PARK) [A.3]: ability of the PP to accept a manual entry of the 
PARK for ensuring attachment to the right FP in a physical area covered by many providers. 

terminal identity number assignment in mono-cell system [A.4]: ability to assign to each PT a terminal identity 
number. 

F.2.4 DLC service definitions (clause 5.1 of EN 300 444) 

LAPC class A service and Lc [D.l]: single frame acknowledged C-plane data link service providing a single data link 
between one FT and one PT. 

The higher layer information is segmented (if necessary) and transmitted in numbered frames. The Lc provides frame 
delimiting, transparency and frame synchronization. 

Cs channel fragmentation and recombination [D.2]: Lc service providing channel dependant fragmentation (by 
means of dividing a LAPC data unit into more than one service data units for delivery to the MAC layer Cs logical 
channel) and recombination (by means of joining several service units received from the MAC layer Cs logical channel 
into a LAPC data unit). 

broadcast Lb service [D.3]: simplex point-to-multipoint transmission using simple fixed length DLC frames providing 
a restricted broadcast service in direction FP to PP(s). 

intra-cell voluntary connection handover [D.4]: internal handover process provided and initiated by the DLC layer 
(e.g. as a result of continued poor quality of service from the MAC layer), whereby one set of DLC entities (C-plane 
and U-plane) can re-route data from one MAC connection to a second new MAC connection in the domain of the same 
cell, while maintaining the service provided to the NWK layer. 

intercell voluntary connection handover [D.5]: internal handover process provided and initiated by the DLC layer 
(e.g. as a result of continued poor quality of service from the MAC layer), whereby one set of DLC entities (C-plane 
and U-plane) can re-route data from one MAC connection to a second new MAC connection not in the domain of the 
same cell, while maintaining the service provided to the NWK layer. 

encryption activation [D.6]: transporting the NWK layer encryption request and the cipher key to the MAC layer, 
thereby enabling the encryption process in the MAC layer. 

LUl TRansparent Unprotected service (TRUP) class 0/min_delay [D.7]: transparent unprotected service 
introducing minimum delay between the higher layers and the MAC layer. 

May be used for speech and non-speech applications. Speech transmission should only use the class 0/min_delay 
operation over a single bearer MAC connection. Data integrity is not guaranteed. No error protection is applied, and 
octets may be lost, erroneous or duplicated. The continuous higher layer data is fragmented for delivery to the In logical 
channel in the transmission direction, and recombined from the In logical channel in the receiving direction. 

FUl [D.8]: offers a defined fixed length frame structure and buffering functions for transmission of U-plane data to the 
MAC layer (at the transmit side) or accept of data from the MAC layer (at the receiving side) on demand and with 
minimum delay. Used for speech but may be used for more general data purposes. 

encryption deactivation [D.9]: transporting the NWK layer encryption deactivation request to the MAC layer, thereby 
disabling the encryption process in the MAC layer. 
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F.2.5 GAP MAC service definitions (clause 5.2 of EN 300 444) 

general [M.l]: set of basic requirements regarding data formats, multiplexing, CRC usage, scanning and locking, 
which are prerequisites to communication between peer MAC entities. 

continuous broadcast [M.2]: simplex service from FT to PT whereby the FT maintains at least one bearer with 
continuous transmissions. The PT can use the information carried in this bearer to lock to the FT and to obtain 
knowledge about the FT. 

paging broadcast [M.3]: service whereby the identities of specific PTs can be broadcast by the FT. This service is 
normally used by the FT to request a specific PT to set up a link to the FT. 

basic connection [M.4]: service providing connection between FT and PT consisting of one full slot duplex bearer 
supporting the In_minimum_delay data service (i.e. speech). Only one basic connection may exist between a FT and 
particular PT (except during connection handover). The service includes the means for setting-up and releasing the 
required bearer(s). 

Cg higher layer signalling [M.5]: low rate connection oriented data service with ARQ using the C5 channel to transfer 
higher layer signalling data. 

quality control [M.6]: provides means for monitoring and controlling the radio link quality. 

encryption activation [M.7]: service providing means for enabling the encryption whereby on demand all higher layer 
data (including speech) is transferred across the AI in an encrypted form. Always initiated by the PT. 

extended frequency allocation [M.8]: service which allows a FT to support frequencies in addition to the standard 
DECT frequencies. 

bearer handover - intra-cell [M.9]: internal MAC process whereby data transfer (C channel and I channel) is switched 
from one duplex bearer to another in the domain of the same cell while maintaining the service to the DLC layer. 

bearer handover - inter-cell [M.IO]: internal MAC process whereby data transfer (C channel and I channel) is 
switched from one duplex bearer to another not in the domain of the same cell while maintaining the service to the DLC 
layer. 

connection handover - intra-cell [M.ll]: in the MAC layer, it is the process enabling setting up a new basic 
connection in the domain of the same cell to support connection handover at the DLC layer. 

connection handover - inter-cell [M.12]: in the MAC layer, it is the process enabling setting up a new basic 
connection not in the domain of the same cell to support connection handover at the DLC layer. 

Secondary Access Rights Identity (SARI) support [M.13]: ability to support, in addition to the primary Access 
Rights Identity (ARI), secondary ARIs that the FT broadcasts less frequently than PARIs. These may be used to reflect 
an inter-operators agreement allowing a portable to access more than one operator or services through FT. 

encryption deactivation [M.14]: service providing means for disabling the encryption whereby on demand the process 
of transmitting higher layer data (including speech) across the AI in encrypted form is to be cancelled (a connection 
release automatically disables ciphering). 

Re-keying [M.15]: mechanism to change the cipher key during an ongoing call. 

Early encryption [M.16]: mechanism to activate encryption immediately after connection establishment. 

AES/DSC2 encryption [M.17]: encryption using the DSC2 algorithm, based on AES, with Cipher Key of 128 bits. 



F.3 Services and features defined in TS 1 02 527-3 
(NG-DECT Part 3) 

The following informative annex shows the features and services defined in TS 102 527-3 [18] (New Generation 
DECT; Part 3: extended wideband speech services), that are reused in the present document. This list is informative, 
and shows the status in TS 102 527-3 (VI. 4.1) [18]. Where there are changes or divergences the original definitions at 
TS 102 527-3 [18] apply. 
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F.3.1 New Generation DECT; part 3, Speech Services (clause 5.1 
of TS 1 02 527-3) 

No additional speech services are defined in TS 102 527-3 [18]. The definitions of TS 102 527-1 [17], clause 5.1 apply. 

F.3.2 New Generation DECT; part 3, Network (NWK) features 
(clause 5.2 of TS 102 527-3) 

Missed call notification [NG1.N.3]: ability to inform a user that a call has been missed. 

Voice message waiting notification [NG1.N.4]: ability to inform a user that a voice message has been left in the voice 
mailbox to which the user has access. 

Date and time synchronization [NG1.N.5]: ability to synchronize the date and time on the DECT system. From FP to 
all registered PP or from one registered PP to the FP. 

Parallel calls [NG1.N.6]: ability to handle in the DECT system two or more simultaneous calls originated or 
terminated in the same PP. 

Common parallel call procedures (external or internal) [NG1.N.7]: set of common procedures for handling PSTN 
double calls, SIP multiple calls on a single line, as well as parallel call situations occurring in a multiple line DECT 

system. 

Call transfer (internal or external) [NG1.N.8]: ability to create a new call while already involved in a call and 
connect the remote party to it (kind of parallel calls). 

3-party conference call (internal or external) [NG1.N.9]: ability to connect the local party and the two remote parties 
of two parallels calls into a single conference (kind of parallel calls). 

Intrusion call [NGl.N.lO]: ability for a PP not participating to an already established call to connect to it (kind of 
parallel calls). Intrusion call is also known as "barging in". 

Call deflection [NGl.N.ll]: ability to redirect an incoming call during the call presentation to another user. 

Line identification [NG1.N.12]: ability to exchange between the PP and FP a line identifier for external calls. 

Call identification [NG1.N.13]: ability to exchange between the PP and FP a call identifier assigned by the FP at call 
setup and call statuses from FP to PP. 

Multiple lines [NG1.N.14]: abiUty for a DECT System to handle several external lines. 

Multiple calls [NG1.N.15]: ability for a DECT System to handle a line supporting several simultaneous external calls. 

List access service [NG1.N.16]: ability to store information on the DECT system in a set of lists on the FP and manage 
these lists from the PP. 

Calling Line Identity Restriction (CLIR) [NG1.N.17]: abihty for the user to hide the identity of his line (i.e. Calling 
Line Identity Presentation) to the called party. 

Call forwarding [NG1.N.18]: ability to request to the network a redirection of incoming calls. 

DTMF handling [NG1.N.19]: ability to handle DTMF signalhng and generation. 

Tones provision [NG1.N.20]: ability to support complete call progress tones generation. 

Headset management [NG1.N.21]: abihty to handle calls with a headset PP in a DECT system. 

Handling of lines where second calls are signalled in-band [NG1.N.22]: ability to handle second calls on PSTN lines 
or lines following similar rules. 
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F.3.3 New Generation DECT; part 3, DLC Services (clause 5.3 of 
TS 1 02 527-3) 

No additional speech services are defined in TS 102 527-3 [18]. The definitions given in TS 102 527-1 [17], clause 5.3 
and in EN 300 444 [11], clause 5.1 apply. 

F.3.4 New Generation DECT; part 3, IVIAC Services (clause 5.4 of 
TS 1 02 527-3) 

"no emission" mode [NG1.M.5]: ability to deactivate all radio transmissions in a DECT FP when it does not handle 
any call. Power-down is negotiated and an algorithm is provided, that guarantees a short resynchronization time, if an 
RF-connection is required by any of the peers. 

F.3.5 New Generation DECT; part 3, Physical Layer (PHL) 
Services (clause 5.5 of TS 102 527-3) 

No additional Physical Layer (PHL) services are defined in TS 102 527-3 [18]. The definitions given in 
TS 102 527-1 [17], clause 5.5 apply. 

F.3.6 New Generation DECT; part 3, Speech coding and audio 
features (clause 5.6 of TS 102 527-3) 

No additional Speech coding and audio features are defined in TS 102 527-3 [18]. The definitions given in 
TS 102 527-1 [17], clause 5.6 apply. 

F.3.7 New Generation DECT; part 3, Application features 
(clause 5.7 of TS 102 527-3) 

Easy PIN code registration [NGl.A.l]: ability to invite the user to register a PP that is not registered to a FP. The 
access rights procedure is triggered by PIN entering. 

Easy pairing registration [NG1.A.2]: ability to register a PP that is not registered to a FP by pressing a physical or 
logical button on the PP and on the FP. 

Handset locator [NG1.A.3]: ability to locate physically handsets (have them ring) by pressing a physical or logical 
button on the FP. 



F.4 GAP Feature/service to procedure mapping tables 

The following informative annex shows the features/service to procedure mapping tables as defined in EN 300 444 [11] 
(GAP), that are reused in the present document (unless other specification is given). This list is informative, and shows 
the status in EN 300 444 [11]. Where there are changes or divergences the original definitions at EN 300 444 [11] 
(GAP) apply. 
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F.4.1 GAP NWK feature to procedure mapping table (clause 6.8.1 
of EN 300 444) 

Table F.I : NWK feature to procedure mapping (table 5 of EN 300 444) 



Feature supported 




Status 


Item no. 


Name of feature 


Reference 


PT 


FT 1 










R/B 


p 


N.35 


Outgoing call 


4.1 


M 


M 


M 


N.36 


Off hook 


4.1 


M 


M 


M 


N.37 


On hook (full release) 


4.1 


M 


M 


M 


N.38 


Dialled digits (basic) 


4.1 


M 


M 


M 


N.39 


Register recall (see notes 4 and 5) 


4.1 


M 








N.40 


Go to DTIVIF signalling (defined tone length) (see note 1) 


4.1 


M 





M 


N.41 


Pause (dialling pause) (see note 3) 


4.1 


M 








N.42 


Incoming call 


4.1 


M 


M 


M 


N.43 


Authentication of PP 


4.1 


M 


C101 


M 


N.44 


Authentication of user (see note 2) 


4.1 


M 








N.45 


Location registration 


4.1 


M 





M 


N.46 


On air key allocation (see note 2) 


4.1 


M 


C101 





N.47 


Identification of PP 


4.1 


M 








N.48 


Service class indication/assignment 


4.1 


M 





M 


N.49 


Alerting 


4.1 


M 


M 


M 


N.50 


ZAP (see note 2) 


4.1 


M 








N.51 


Encryption activation FT initiated 


4.1 


M 


C101 


M 


N.52 


Subscription registration procedure on-air 


4.1 


M 


M 


M 


N.53 


Link control 


4.1 


M 


M 


M 


N.54 


Terminate access rights FT initiated (see note 2) 


4.1 


M 








N.55 


Partial release 


4.1 











N.56 


Go to DTMF (infinite tone length) 


4.1 











N.57 


Go to Pulse 


4.1 











N.58 


Signalling of display characters 


4.1 











N.59 


Display control characters 


4.1 











N.60 


Authentication of FT 


4.1 











N.61 


Encryption activation PT initiated 


4.1 











N.62 


Encryption deactivation FT initiated 


4.1 











N.63 


Encryption deactivation PT initiated 


4.1 











N.64 


Calling Line Identification Presentation (CLIP) 


4.1 











N.65 


Internal call 


4.1 











N.32 


Service call 


4.1 











N.33 


Enhanced U- plane connection 


4.1 











N.34 


Calling Name Identification Presentation (CNIP) 


4.1 











N.35 


Enhanced security 


4.1 











N.36 


AES/DSAA2 authentication 


4.1 


C102 


C102 


C102 


NOTE 1 : The PT is only required to be able to send the «MULTI-KEYPAD» information element containing the 

DECT standard 8-bit character (EN 300 175-5 [5], annex D) codings "Go to DTMF", defined tone length 

and the FT is required to be able to understand it in the public environment. 
NOTE 2: This feature is required to be supported in the PT to guarantee the same level of security among all the 

handsets that operates in a system. The invocation of the feature is however optional to the operator. 
NOTE 3: The PT is required to be able to send the «MULTI-KEYPAD» information element containing the DECT 

standard 8-bit character (EN 300 175-5 [5], annex D) codings "Dialling Pause". This guarantees 

automatic access to secondary or alternative networks. 
NOTE 4: This feature uses keypad code 15 hex. 
NOTE 5: The FT is not mandated to receive and understand the register recall DECT character. However, if a FT 

supports it there may be no corresponding action that the FT can take with the local network as a result of 

this function. 


C101: IF feature N.35 THEN M ELSE 0. 

CI 02: IF MAC service M.17 THEN M ELSE 0. 
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F.4.2 GAP DLC service to procedure mapping table (clause 6.8.2 
of EN 300 444) 

Table F.2: DLC service to procedure mapping (table 6 of EN 300 444 [11]) 



Service/Procedure mapping 




Status 


Service 


Procedure 


Reference 


PT 


FT 1 










R/B 


P 


D.1 LAPC class A service and Lc 




5.1 


M 


M 


M 


Class A link establishment 


9.1 


M 


M 


M 


Class A acknowledged information 
transfer 


9.2 


M 


M 


M 


Class A link release 


9.3 


M 


M 


M 


Class A link re-establishment 


9.4 


M 


M 


M 


D.2 Cg channel fragmentation and 
recombination 




5.1 


M 


M 


M 


Cg channel fragmentation and 
recombination 


9.5 


M 


M 


M 


D.3 Broadcast Lb service 




5.1 


M 


M 


M 


Normal broadcast 


9.6 


M 


M 


M 


D.4 Intra-cell voluntary connection 
handover 




5.1 


M 


C001 


C001 


Class A basic connection handover 


9.7 


M 


M 


M 


D.5 Inter-cell voluntary connection 
handover 




5.1 


M 








Class A basic connection handover 


9.7 


M 


M 


M 


D.6 Encryption activation 




5.1 


M 


COOS 


M 


Encryption switching 


9.8 


M 


M 


M 


D.7 LU1 TRUP Class 0/min_delay 




5.1 


M 


M 


M 


U-plane Class 0/min delay 


9.9 


M 


M 


M 


D.8 FU1 




5.1 


M 


M 


M 


FU1 frame operation 


9.10 


M 


M 


M 


D.9 Encryption deactivation 




5.1 


C002 


C002 


C002 


Encryption switching 


9.8 


M 


M 


M 


C001: IF service M.9 THEN ELSE M. 

C002: IF feature N.29 OR N.28 THEN M ELSE 1. 

COOS: IF feature N.17 OR N.27 THEN M ELSE 1. 



F.4.3 GAP IVIAC service to procedure mapping table (clause 6.8.3 
of EN 300 444) 

Table F.3: MAC service to procedure mapping (table 7 of EN 300 444 [11]) 



Service/Procedure mapping 




Status 1 


Service 


Procedure 


Reference 


PT 


FT 1 










R/B 


P 


M.1 General 




5.2 


M 


M 


M 


General 


10.1 


M 


M 


M 


M.2 Continuous broadcast 




5.2 


M 


M 


M 


Downlink broadcast 


10.2 


M 


M 


M 


Higher Layer capability FP broadcast 


13.6 


M 


M 


M 


IVI.S Paging broadcast 




5.2 


M 


M 


M 


Paging broadcast 


10.3 


M 


M 


M 


M.4 Basic connections 




5.2 


M 


M 


M 


Setup of basic connection, basic bearer 
setup (A-field) 


10.4 


M 


M 


M 


Connection/bearer release 


10.5 


M 


M 


M 


M.5 Cg higher layer signalling 




5.2 


M 


M 


M 


Cg channel data 


10.8 


M 


M 


M 


02 bit setting 


10.9 


M 


M 


M 
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Service/Procedure mapping 




Status 1 


Service 


Procedure 


Reference 


PT 


FT 1 










R/B 


P 


M.6 Quality control 




5.2 


M 


M 


M 


RFPI handshake 


10.10 


M 


M 


M 


Antenna diversity 


10.11 


M 








Sliding collision detection 


10.12 





M 


M 


M.7 Encryption activation 




5.2 


M 


C004 


M 


Encryption process - initialization and 
synchronization 


10.13 


M 


M 


M 


Encryption mode control 


10.14 


M 


M 


M 


Handover encryption process 


10.15 


M 


M 


M 


M.8 Extended frequency 
allocation 




5.2 


M 








Extended frequency allocation 


10.16 


M 


M 


M 


IVI.Q Bearer handover, intra-cell 




5.2 


M 


C001 


C001 


Bearer handover request 


10.6 


M 


M 


M 


M.10 Bearer handover, inter-cell 




5.2 


M 








Bearer handover request 


10.6 


M 


M 


M 


M.11 Connection handover, intra- 
cell 




5.2 


M 


C002 


C002 


Connection handover request 


10.7 


M 


M 


M 


M.I 2 Connection handover, inter- 
cell 




5.2 


M 








Connection handover request 


10.7 


M 


M 


M 


M.13 SARI support 




5.2 


M 








Downlink broadcast 


10.2 


M 


M 


M 


Higher Layer capability FP broadcast 


13.6 


M 


M 


M 


M.I 4 Encryption deactivation 




5.2 


COOS 


COOS 


COOS 


Encryption mode control 


10.14 


M 


M 


M 


M.15 Re-keying 




5.2 


C705 


C705 


C705 


Re-keying 


10.17 


M 


M 


M 


M.I 6 Early encryption 




5.2 


C706 


C706 


C706 


Early encryption 


10.18 


M 


M 


M 


M.17 AES/DSC2 encryption (see 
note) 




5.2 











AES/DSC2 encryption 


10.19 


M 


M 


M 


NOTE: IF implemented THEN NWK feature N.36 should be implemented. 


C001 
C002 
COOS 
C004 
C705 
C706 


IF service M.1 1 THEN ELSE M. 

IF service M.9 THEN ELSE M. 

IF feature N.29 OR N.28 THEN M ELSE 1. 

IF feature N.17 OR N.27 THEN M ELSE 1. 

IF feature N.35 and NWK layer procedure "Re-keying during a call" are implemented THEN M ELSE 0. 

IF feature N.35 and NWK layer procedure "Early encryption" are implemented THEN M ELSE 0. 



F.4.4 GAP Application feature to procedure mapping table 
(clause 6.8.4 of EN 300 444) 

Table F.4: Application feature to procedure mapping table (table 8 of EN 300 444 [11]) 



Feature/Procedure mapping 




Status 1 


Feature 


Procedure 


Reference 


PT 


FT 1 










R/B 


P 


A.I AC to bitstring mapping 




4.S 


M 


C001 


M 


AC to bitstring mapping 


14.2 


M 


M 


M 


A.2 Multiple subscription 
registration 




4.3 


M 


N/A 


N/A 


Subscription control 


14.1 


M 


N/A 


N/A 


A.S Manual entry of the PARK 




4.3 





N/A 


N/A 


Manual entry of the PARK 


14.3 


M 


N/A 


N/A 


A.4 Terminal identity number 
assignment in mono cell system 




4.3 








N/A 


Terminal identity number assignment 


14.4 








N/A 


C001 : IF feature N.9 OR N.10 OR N.I 2 OR N.26 THEN M ELSE N/A. 
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F.5 NG-DECT Part 3 feature/service to procedure 
mapping tables 

The following informative annex shows the features/service to procedure mapping tables as defined in 
TS 102 527-3 [18] (New Generation DECT; Part 3: extended wideband speech services), that are reused in the present 
document (unless other specification is given). This list is informative, and shows the status in TS 102 527-3 [18] 
VI. 4.1. Where there are changes or divergences the original definitions at TS 102 527-3 [18] apply. 

F.5.1 NG-DECT Part 3 NWK feature to procedure mapping table 
(clause 6.10 of TS 102 527-3) 

The NWK features to procedure mapping of EN 300 444 [11] (GAP), clause 6.7 with the following changes and 
additional features apply: 

Table F.5: NWK feature to procedure mapping (table 9 of TS 102 527-3 [18]) 



Feature/Procedure mapping 




Status 1 


Feature 


Procedure 


Reference 


PT 


FT 1 


R/B 


P 


NG1.N.1 Codec Negotiation 




5.2 [17] 


M 


M 


M 


Exchange of codec list during registration 
and location registration 


7.3.1 [17] 


M 


M 


M 


Basic service wideband speech and 
default attributes 


7.3.2 [17] 


M 


M 


M 


Codec Negotiation during call 
establishment 


7.3.3 [17] 


M 


M 


M 


NG1 .N.2 Codec Switcliing 




5.2 [17] 


M 


M 


M 


Codec Change 


7.3.4 [17] 


M 


M 


M 


Slot type modification 


7.3.5 [17] 


M 


M 


M 


IVIAC layer advanced connection slot type 
modification 


7.6.7 [17] 


M 


M 


M 


IVIAC layer connection type modification: 
basic to/from advanced 


7.6.6 [17] 


M 


M 


M 


NG1.N.3 IVIissed call notification 




5.2 


M 


M 


M 


Generic events notification, general 


7.4.1.1 


M 


M 


M 


IVIissed call notification 


7.4.1.3 


M 


M 


M 


NG1 .N.4 Voice message waiting 
notification 




5.2 


M 


M 


M 


Generic events notification, general 


7.4.1.1 


M 


M 


M 


Voice message waiting notification 


7.4.1.2 


M 


M 


M 


NG1.N.5 Date and Time 
synclironization 




5.2 


M 


M 


M 


Date and Time synchronization 


7.4.2 


M 


M 


M 


Date and Time recovery 


7.4.20 











NG1.N.6 Parallel Calls 




5.2 


M 


M, 
note 2 





Parallel call common requirements 


7.4.3.1 


M 


M 


M 


Control messages 


7.4.3.2 


M 


M 


M 


Sending Keypad information 


8.10[11] 


M 


M 


M 


Codec change for parallel calls 


7.4.3.3 


M 


M 


M 


Sending negative acknowledgement 


7.4.3.4 


M 


M 


M 


Busy system or line notification 


7.4.8.3 


M 


M 


M 


NG1 .N.7 Common parallel call 
procedures (external or internal) 




5.2 


M 


M, 
note 2 





Outgoing parallel call initiation (external 
or internal) 


7.4.3.5.1 


M 


M 


M 


Call waiting indication (external or 
internal) 


7.4.3.5.2 


M 


M 


M 


Call toggle (external or internal) 


7.4.3.5.3 


M 


M 


M 


Call release and call release rejection 


7.4.3.5.4 


M 


M 


M 


Call waiting acceptance (from PP to FP) 


7.4.3.5.6 


M 


M 


M 


Call waiting rejection (from PP to FP) 


7.4.3.5.7 


M 


M 


M 
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Feature/Procedure mapping 




Status 1 


Feature 


Procedure 


Reference 


PT 


FT 1 


R/B 


P 


Active call release with replacement (from 
PP to FP) 


7.4.3.5.12 





M 


M 


Putting a call on-hold 


7.4.3.5.8 





M 


M 


Resuming a call put on-hold 


7.4.3.5.9 





M 


M 


CLIP on call waiting indication 


7.4.3.5.10 


M 


M 


M 


CNIP on call waiting indication 


7.4.3.5.11 


M 


M 


M 


NG1 .N.8 Call transfer (external or 
internal) 




5.2 


M 


M 





Announced call transfer 


7.4.3.6.1 


M 


M 


M 


Unannounced call transfer 


7.4.3.6.2 


M 


M 


M 


Call re-injection to the system (external or 
internal) 


7.4.3.6.3 


M 


M 


M 


Remote party CLIP on call transfer 


7.4.3.6.4 


M 


M 


M 


Remote party CNIP on call transfer 


7.4.3.6.5 


M 


M 


M 


NG1 .N.9 3-party conference call 
(external or Internal) 




5.2 





0, 
note 1 


0, 
note 1 


3-party Conference with established 
internal and external calls 


7.4.3.7 


M 


M 


M 


NG1.N.10 Intrusion call 




5.2 





0, 
note 1 


0, 
note 1 


Implicit intrusion call into a line in "single 
call" mode 


7.4.3.8.1 


C901 


M 


M 


Explicit intrusion call (from PP to FP) 


7.4.3.8.2 


C901 


M 


M 


NG1.N.11 Call deflection (internal 
or external) 




5.2 





0, 
note 1 


0, 
note 1 


Call deflection (internal) 


7.4.4.2 


M 


M 


M 


Call deflection (external) 


7.4.4.2 


M 


M 


M 


Call deflection control messages 


7.4.4.1.1 


M 


M 


M 


NG1.N.12 Line identification 




5.2 


M 


M 


M 


Line identification general requirements 


7.4.5.1 


M 


M 


M 


General line identification requirements 
for external outgoing calls 


7.4.5.2.1 


M 


M 


M 


Line identification for a first external 
outgoing call using «CALL-INFO» IE 


7.4.5.2.2 


M 


M 


M 


Line identification for a first external 
outgoing call using «MULTI-KEYPAD» 
IE 


7.4.5.2.3 


1 
(note 5) 








FP managed line selection for a first 
external outgoing call 


7.4.5.2.4 


M 


M 


M 


General line identification requirements 
for external incoming calls 


7.4.5.3.1 


M 


M 


M 


Line identification for a first external 
incoming call 


7.4.5.3.2 


M 


M 


M 


NG1.N.13 Call identification 




5.2 


M 


M 


M 


Call identifier general requirements 


7.4.6.1 


M 


M 


M 


Call identifier assignment on outgoing call 
(FP to PP) 


7.4.6.2 


M 


M 


M 


Call identifier assignment on incoming 
call (FP to PP) 


7.4.6.3 


M 


M 


M 


Call status indication to the handset 


7.4.6.4 


M 


M 


M 


NG1.N.14l\/lultiple lines 




5.2 


M 








IVIultiple lines common requirements 


7.4.7.1 


M 


M 


M 


Terminal attachment and line settings 


7.4.7.2 


M 


M 


M 


Incoming and outgoing external calls on a 
multiple line system 


7.4.7.3 


M 


M 


M 


Internal calls in multiple line context 


7.4.7.4 


M 


M 


M 


Compatibility with non multiple line PP or 
FP 


7.4.7.5 


M 


M 


M 
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Feature/Procedure mapping 




Status 1 


Feature 


Procedure 


Reference 


PT 


FT 1 


R/B 


P 


NG1.N.15 Multiple calls 




5.2 


M 


M 





IVIultiple calls general requirements 


7.4.8.1 


M 


M 


M 


Incoming and outgoing external calls on a 
multiple call line 


7.4.8.2 


M 


M 


M 


Busy system or line notification 


7.4.8.3 


M 


M 


M 


NG1 .N.1 6 List access service 




5.2 


M 


M 





General considerations 


7.4.10.1 


M 


M 


M 


List change notification 


7.4.10.2 





M 


M 


Start / end session (note 4) 


7.4.10.4.1 


M 


M 


M 


Query supported entry fields (note 4) 


7.4.10.4.2 





M 


M 


Read entries (note 4) 


7.4.10.4.3 


M 


M 


M 


Edit entry (note 4) 


7.4.10.4.4 


M 


M 


M 


Save entry (note 4) 


7.4.10.4.5 


M 


M 


M 


Delete entry (note 4) 


7.4.10.4.6 


M 


M 





Delete list (note 4) 


7.4.10.4.7 


M 


M 


M 


Search entries (note 4) 


7.4.10.4.8 


M 


M 


M 


Negative acknowledgement 


7.4.10.4.9 


M 


M 


M 


Data packet / Data packet last 


7.4.10.4.10 


M 


M 


M 


DECT system and line settings 
considerations 


7.4.11.1 


M 


M 





Interactions between registration, 
attachment of handsets and lists 


7.4.11.2 


M 


M 





Fields description 


7.4.10.5.1 


M 


M 


M 


[Supported lists] 










List of Supported Lists 


7.4.10.5.2 





M 


M 


Missed Calls List 


7.4.10.5.3 


M 


M 


M 


Outgoing Calls List 


7.4.10.5.4 











Incoming Accepted Calls List 


7.4.10.5.5 


M 


M 


M 


All Calls List 


7.4.10.5.6 











Contact List 


7.4.10.5.7 


M 


M 


M 


Internal Names List 


7.4.10.5.8 


M 


M 


M 


All Incoming Calls List 


7.4.10.5.11 
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Feature/Procedure mapping 




Status 1 


Feature 


Procedure 


Reference 


PT 


FT 1 


R/B 


P 


DECT System Settings List 


7.4.11.3 


M 


M 





Line Settings List 


7.4.11.4 


M 


M 





Virtual Contact List and call list per line 


7.4.11.5 





C902 





[Supported DECT system settings] 










Current PIN code 


7.4.11.3.1 


M 


M 





Clock master 


7.4.11.3.2 


M 


M 





Base reset 


7.4.11.3.3 


M 


M 





FP IP address /type 


7.4.11.3.4 











FP IP address /value 


7.4.11.3.5 











FP IP address / subnet mask 


7.4.11.3.6 











FP IP address / gateway 


7.4.11.3.7 











FP IP address / DNS server 


7.4.11.3.8 











FP version / Firmware version 


7.4.11.3.9 


M 


M 





FP version / EEprom version 


7.4.11.3.10 


M 


M 





FP version / Hardware version 


7.4.11.3.11 











Emission mode 


7.4.11.3.12 


C903 


C903 





New PIN code 


7.4.11.3.13 


M 


M 





[Supported line settings] 










Line name 


7.4.11.4.1 


M 


M 





Line id 


7.4.11.4.2 


M 


M 





Attached handsets 


7.4.11.4.3 


M 


M 





Dialling prefix 


7.4.11.4.4 











FP melody 


7.4.11.4.5 











FP volume 


7.4.11.4.6 











Blocked number 


7.4.11.4.7 











Multiple calls mode (single/multiple) 


7.4.11.4.8 


M 


M 


M 


Intrusion call 


7.4.11.4.9 


C904 


C904 


C904 


Permanent CLIR 


7.4.11.4.10 


C905 


C905 


C905 


Call forwarding Unconditional 


7.4.11.4.11 


M 


M 


1 


Call forwarding on No Answer 


7.4.11.4.12 


M 


M 


1 


Call forwarding on Busy subscriber 


7.4.11.4.13 


M 


M 


1 


NG1.N. 17 Calling line identity 
restriction 




5.2 











Considerations 


7.4.12.1 


M 


M 





Permanent CLIR mode (all calls) 


7.4.12.2 


M 


M 





Temporary CLIR mode (call by call) 


7.4.12.3 


M 


N/A 





NG1.N.18 Call forwarding 
(external calls) 




5.2 


M 


M 


1 


Call Forwarding common requirements 


7.4.13.1 


M 


M 


1 


External Call Forwarding Unconditional 
(CFU) to external number 


7.4.13.2 


M 


M 


1 


External Call Forwarding on No Answer 
(CFNA) to external number 


7.4.13.3 


M 


M 


1 


External Call Forwarding on Busy 
subscriber (CFB) to external number 


7.4.13.4 


M 


M 


1 


NG1.N.19DTMF handling 




5.2 


M 


M 





Uplink DTIVIF transmission at call setup 
when FP connected to classic switching 
network 


7.4.14.1.1 


M 


C906 


C906 


Uplink DTIVIF transmission when 
connected 


7.4.14.1.2 


M 


M 





Downlink DTIVIF reception 


7.4.14.2 


M 


M 





Local DTMF feedback of dialled digits 


7.4.14.3 


M 


M 





NG1 .N.20 Tones provision 




5.2 


M 


M 





General considerations 


7.4.15.1 


M 


M 





Tones provision by the system 


7.4.15.2 


M 


M 





Transparency to tones provision by the 
network or PABX 


7.4.15.3 


M 


M 
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Feature/Procedure mapping 




Status 1 


Feature 


Procedure 


Reference 


PT 


FT 1 


R/B 


P 


NG1.N.21 Headset management 




5.2 


C907 


M 





Headset considerations 


7.4.16.1 


C907 


M 





Headset call interception 


7.4.16.2 


C907 


M 





Headset incoming call 


7.4.16.3 


C907 


M 





Re-dial of last outgoing call 


7.4.16.4 


C908 


M 





Re-dial of last incoming call 


7.4.16.5 


C908 


M 





Switching from headset to handset 
(headset initiated) 


7.4.16.6 


C908 


M 





Switching from headset to handset 
(handset initiated) 


7.4.16.7 


C909 


M 





Compatibility with other telephony 
features and profiles 


7.4.16.8 


C907 


M 





NG1 .N.22 Handling of lines where 
second calls are signalled in-band 




5.2 


M 



note 2 





General requirements 


7.4.3.10.1 


1 


M 


M 


Basic 'double call with in-band signalling' 
lines 


7.4.3.10.2 


1 


M 
note 3 


M 


Off-hook CLIP enabled 'double call with 
in-band signalling' lines 


7.4.3.10.3 


M 


M 
note 3 


M 


Use of transparent commands on DCIBS 
lines (Basic or Off-hook CLIP enabled) or 
any other line 


7.4.3.10.4 


M 


M 


M 


GAP. N. 11 Location registration 




4.1 [11] 


M 





M 


Location registration 


8.28 [11] 


M 


M 


M 


Location update 


8.29 [11] 


M 








Terminal Capability indication 


7.4.9.1 


M 


M 


M 


Location registration after re-lock 


7.4.18 


M 


N/A 


N/A 


GAP.N.14 Service class 
indication/assignment 




4.1 [11] 


M 





M 


Obtaining access rights 


8.30 [11] 


M 


M 


M 


Terminal Capability indication 


7.4.9.1 


M 


M 


M 


Authentication of PP using DSAA 


8.24(11] 


M 


M 


M 


Authentication of PP using DSAA2 


8.24(11] 


C910 


C910 


C910 


GAP. N.I 5 Alerting 




4.1 [11] 


M 


M 


M 


PT Alerting 


8.14(11] 


M 


M 


M 


PT Alerting using pattern signaling 


7.4.19 


M 


M 


M 


GAP. N. 16 ZAP 




4.1(11] 


M 








Obtaining access rights 


8.30(11] 


M 


M 


M 


Terminal Capability indication 


8.17(11] 


M 


M 


M 


Incrementing the ZAP value 


8.26(11] 


M 


M 


M 


Authentication of FT using DSAA 


8.23(11] 





M 


M 


Authentication of FT using DSAA2 


8.45.6(11] 


C911 


C910 


C910 


GAP. N. 18 Subscription 
registration user procedure on-air 




4.1(11] 


M 


M 


M 


Obtaining access rights 


8.30(11] 


M 


M 


M 


Terminal Capability indication 


7.4.9.1 


M 


M 


M 


GAP. N.I 9 Link control 




4.1(11] 


M 


M 


M 


Indirect FT initiated link establishment 


7.3.8(17] 


M 


M 


M 


Direct PT initiated link establishment 


8.36(11] 


M 


M 


M 


Link release "normal" 


8.37(11] 


M 


M 


M 


Link release "abnormal" 


8.38(11] 


M 


M 


M 


Link release "maintain" 


8.39(11] 


M 


M 


M 


GAP. N. 24 Signalling of display 
characters 




4.1(11] 











Display 


8.16(11] 


M 


M 


M 


Terminal capability indication 


7.4.9.1 


M 


M 


M 


GAP.N.25 Display control 
characters 




4.1(11] 











Display 


8.16(11] 


M 


M 


M 


Terminal capability indication 


7.4.9.1 


M 


M 


M 


GAP.N.31 Intemal Call 




4.1(11] 


M 


M 


M 


Internal call setup 


7.3.6(17] 


M 


M 


M 


Internal call keypad 


8.19(11] 


M 








Internal call CLIP 


8.43(11] 


M 


M 


M 
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Feature/Procedure mapping 




Status 1 


Feature 


Procedure 


Reference 


PT 


FT 1 


R/B 


P 


Internal call CNIP 


8.44 [11] 


M 


M 


M 


Internal call codec priority 


7.4.3.9 


M 


M 


M 


UTF-8 CNIP 


7.4.17 


M 


M 


M 


GAP. N.34 Calling Name 
Identification Presentation (CNIP) 




4.1 [111 


M 


M 


M 


Calling Name Identification Presentation 
(CNIP) Indication 


8.42 [11] 


M 


M 


M 


UTF-8 CNIP 


7.4.17 


M 


M 


M 


GAP. N. 35 Enhanced security 




4.1 [111 


M 


M 


M 


Encryption of all calls 


8.45.1 [11] 


M 


M 


M 


Re-keying during a call 


8.45.2 [11] 











Early encryption 


8.45.3 [11] 











Subscription requirements 


8.45.4 [111 


M 


M 


M 


Behaviour against legacy devices 


8.45.5(11] 


M 


M 


M 


C901 
C902 
C903 
C904 
C905 
C906 
C907 
C908 
C909 
C910 
C911 


At least one of the two procedures 7.4.3.8.1 OR 7.4.3.8.2 should be implemented. 

IF NG1 .N.14 THEN "0" ELSE "1". 

IF NG1 .M.5 THEN "M" ELSE "1". 

IF NG1.N.10 THEN "M" ELSE "1". 

IF NG1 .N.17 THEN "M" ELSE "1". 

IF FP is connected to classic switching networks (PSTN for example) THEN "M" ELSE "N/A". 

IF the PT is a headset PP THEN "M" ELSE "1". 

IF the PT is a headset PP THEN "0" ELSE "1". 

IF the PT is a headset PP THEN "1" ELSE "0". 

IF feature GAP.N.36 THEN M ELSE 1. 

IF feature GAP.N.36 THEN ELSE 1. 


NOTE 1 : If tfie corresponding feature is not supported on FT side, the FT should however implement the "sending 

negative acknowledgement" procedure (see clause 7.4.3.4). 
NOTE 2: All procedures of NG1 .N.6 and NG1 .N.7 apply to all FTs and for all line types (full parallel call compliant 

lines and DCIBS lines). For DCIBS lines, the FT implements in addition NG1.N.22 feature, which 

describes some amendments to NG1 .N.6 and NG1 .N.7 for such lines. A given FT should be designed to 

handle both line types, or only one of them. 
NOTE 3: Both procedures are M for the FP. However, for a given line, only one of the procedures 7.4.3.1 0.2 or 

7.4.3.10.3 is used. 
NOTE 4: See also clause 7.4.10.4 for details per list. 
NOTE 5: This procedure is provisioned for GAP and Part 1 PPs and is irrelevant for Part 3 PPs. 
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F.5.2 NG-DECT Part 3 DLC service to procedure mapping table 
(clause 6.11 ofTS 102 527-3) 

The DLC service to procedure mapping of EN 300 444 [11] (GAP), clause 6.8.1, with the following changes and 
additional services apply: 

Table F.6: DLC service to procedure mapping (table 10 of TS 102 527-3) 



Service/Procedure mapping 




Status 1 


Service 


Procedure 


Reference 


PT 


FT 1 


R/B 


P 


NG1.D.1 LU1 Transparent 
Unprotected service (TRUP) 
Class 0/minimum_delay 




5.3 [11] 


M 


M 


M 


LU1 Transparent Unprotected service 
(TRUP) operation 


11.2 [4] 


M 


M 


M 


Class 0: No Lux retransmission or 
sequencing 


14.2.3.1 [4] 


M 


M 


M 


Class procedures 


14.3.2 [4] 


M 


M 


M 


IVIinimum delay (speech) operation 


14.2.3(4] 


M 


M 


M 


LLIVIE U-plane establishment 


9.9.1 [11] 


M 


M 


M 


NG1.D.2LU1 Transparent 
Unprotected service (TRUP) 
Class 




5.3 [17] 


CI 001 


C1001 


C1001 


LU1 Transparent Unprotected service 
(TRUP) operation 


11.2 [4] 


M 


M 


M 


Class 0: No Lux retransmission or 
sequencing 


14.2.3.1 [4] 


M 


M 


M 


Class procedures 


14.3.2 [4] 


M 


M 


M 


LLIVIE U-plane establishment 


9.9.1 [11] 


M 


M 


M 


NG1 .D.3 LU7 64 kbit/s protected 
bearer service 




5.3 [17] 


CI 001 


C1001 


C1001 


LU7 DLC layer service 


11.9.4(4] 


M 


M 


M 


NG1.D.4LU12 Unprotected 
Framed service (UNF) Class 




5.3 [11] 


CI 001 


C1001 


C1001 


LU12 UNprotected Framed service (UNF) 
operation 


11.14 [4] 


M 


M 


M 


Class 0: No Lux retransmission or 
sequencing 


14.2.3.1 [4] 


M 


M 


M 


Class procedures 


14.3.2 [4] 


M 


M 


M 


LLIVIE U-plane establishment 


9.9.1 [11] 


M 


M 


M 


NG1.D.5FU1 DLC frame 




5.3 [11] 


M 


M 


M 


FU1 frame operation 


8.19[111 


M 


M 


M 


FU1 frame structure 


12.2 [4] 


M 


M 


M 


NG1.D.6FU7 DLC frame 




5.3 [11] 


C1001 


C1001 


C1001 


FU7 frame structure 


1 1 .9.4.2 [4] 


M 


M 


M 


NG1 .D.7 FU1 2 DLC frame with 
adaptation for codec G.729.1 




5.3 [11] 


CI 001 


C1001 


C1001 


FU12 frame structure 


12.12 [4] 


M 


M 


M 


Annex for codec G.729.1 


E.I [4] 


M 


M 


M 


FU12frame operation 


7.5.2 [11] 


M 


M 


M 


C1 001 : Status defined by clause 6.3, table 2. 
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F.5.3 NG-DECT Part 3 MAC service to procedure mapping table 
(clause 6.12 of TS 102 527-3) 

The MAC service to procedure mapping of EN 300 444 (GAP) [11], clause 6.8.2, with the following changes and 
additional services apply. 

Table F.7: MAC service to procedure mapping (table 11 of TS 102 527-3 [18]) 



Service/Procedure mapping 




Status 1 


Service 


Procedure 


Reference 


PT 


FT 1 


R/B 


P 


NG1.M.1 lN_minimum delay 
symmetric MAC service type 




5.4 [17] 


M 


M 


M 


MAC layer procedures: general 


7.9.1 [17] 


M 


M 


M 


MAC Connection oriented service 


5.6 3 [3] 


M 


M 


M 


MAC Basic connection 


5.6.1.1 [3] 


M 


M 


M 


MAC Advanced connection 


5.6.1.2 [3] 


M 


M 


M 


lN_minimum delay symmetric MAC service, 
type 1 


5.6.2.1 [3] 


M 


M 


M 


NG1.I\/I.2 lN_normal delay 
symmetric MAC service type 




5.4 [17] 











MAC layer procedures: general 


7.9.1 [17] 


M 


M 


M 


MAC Connection oriented service 


5.6 [3] 


M 


M 


M 


MAC Basic connection 


5.6.1.1 [3] 


M 


M 


M 


MAC Advanced connection 


5.6.1.2 [3] 


M 


M 


M 


lN_normal delay symmetric MAC service 
type 2 


5.6.2.1 [3] 


M 


M 


M 


NG1.M.3 lpQ_error_detection 
symmetric MAC service type 




5.4 [17] 











MAC layer procedures: general 


7.9.1 [17] 


M 


M 


M 


MAC Connection oriented service 


5.6 [3] 


M 


M 


M 


MAC Basic connection 


5.6.1.1 [3] 


M 


M 


M 


MAC Advanced connection 


5.6.1.2 [3] 


M 


M 


M 


lp_error_detection symmetric MAC service 
types 


5.6.2.1 [3] 


M 


M 


M 


Single-subfield protected format 


6.2.1.3.4 [3] 


M 


M 


M 


NG1 .M.4 Advanced connections 




5.4 [17] 


M 


M 


M 


Setup of advanced connection, bearer 
setup (A-field) 


7.6.5 [17] 


M 


M 


M 


Connection type modification: basic to/from 
advanced 


7.6.6 [17] 


M 


M 


M 


Slot type modification 


7.6.7 [17] 


M 


M 


M 


Service type modification 


7.6.8 [17] 


C1101 


C1101 


C1101 


ECN number modification 


7.6.9 [17] 


C1 102 


C1 102 


C1 102 


Connection/bearer release 


7.6.10(17] 


M 


M 


M 


NG1 .M.5 "no-emission" mode 




5.4 











Tail identification for "no emission" mode 


7.1.2 [3] 


M 


M 


M 


Extended Physical and Mac layer 
capabilities (part 2) bit a23 


7.2.3.11 [3] 


M 


M 


M 


Bearer handover/replacement information, 
multiframe-countdown 


7.2.4.3 [3] 


M 


M 


M 


"no emission" mode sync information 


7.3.5.3 [3] 


M 


M 


M 


"no emission" mode procedures 


9.4 [3] 


M 


M 


M 


Management procedures for "no emission" 
mode 


11.11 [3] 


M 


M 


M 


GAP.M.2 Continuous broadcast 




5.2 [11] 


M 


M 


M 


Downlink broadcast 


7.6.3 


M 


M 


M 


Higher Layer information FP broadcast 


7.4.9.2 


M 


M 


M 


GAP.M.3 Paging broadcast 




5.2 [11] 


M 


M 


M 


Paging broadcast 


7.6.4 [17] 


M 


M 


M 












GAP.M.9 Bearer handover, 
intra-cell 




5.2 [11] 


M 


C1 103 


C1 103 


Bearer handover request 


7.6.11 [17] 


M 


M 


M 
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Service/Procedure mapping 




Status 1 


Service 


Procedure 


Reference 


PT 


FT 1 


R/B 


P 


GAP. M. 10 Bearer handover, 
inter-cell 




5.2 [11] 


M 








Bearer handover request 


7.6.11 [17] 


M 


M 


M 


GAP. M. 11 Connection handover, 
intra-cell 




5.2 [11] 


M 


C1 104 


C1 104 


Connection handover request 


7.6.12 [17] 


M 


M 


M 


GAP. M.I 2 Connection handover, 
inter-cell 




5.2 [11] 


M 








Connection handover request 


7.6.12 [17] 


M 


M 


M 


GAP.IVI.13 SARI support 




5.2 [11] 


M 








Downlink broadcast 


7.6.3 


M 


M 


M 


Higher Layer information FP broadcast 


7.4.9.2 


M 


M 


M 


GAP. M.I 5 Re-keying 




5.2 [11] 


C1 105 


C1 105 


C1 105 


Re-keying 


10.17[11] 


M 


M 


M 


GAP. M.I 6 Early encryption 




5.2 [11] 


C1 106 


C1 106 


C1 106 


Early encryption 


10.18[11] 


M 


M 


M 


C1101 
C1102 
C1103 
C1104 
C1105 
C1106 


IF service NG1 .4 OR NG1 .5 OR NG1 .6 OR NG1 .2 lA II OR NG1 .2 lA III THEN M ELSE 0. 

IF multiple connection between the same PT-FT pair THEN M ELSE 0. 

IF service GAP. M.1 1 THEN ELSE M. 

IF service GAP.M.9 THEN ELSE M. 

IF NWK layer procedure "Re-keying during a call" is implemented THEN M ELSE 0. 

IF NWK layer procedure "Early encryption" is implemented THEN M ELSE 0. 
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F.5.4 NG-DECT Part 3 application feature to procedure mapping 
table (clause 6.1 3 of TS 1 02 527-3) 

The Application feature to procedure mapping of EN 300 444 [11] (GAP), clause 6.8.3, with the following changes 
apply. 

Table F.8: Application feature to procedure mapping (table 12 of TS 102 527-3 [18]) 



Feature/Procedure mapping 




Status 1 


Feature 


Procedure 


Reference 


PT 


FT 1 


R/B 


P 


NG1.A.1 Easy PIN code 
registration 




5.7 


M 





N/A 


Registration mode automatic access 


7.10.1.3.1 


M 


N/A 


N/A 


Searching mode and PIN code requests 


7.10.1.1.1 


M 


N/A 


N/A 


Base station name selection 


7.10.1.3.2 








N/A 


Registration user feedback 


7.10.1.3.3 


M 





N/A 


NG1.A.2 Easy pairing registration 




5.7 


M 


M 


N/A 


Easy pairing description 


7.10.1.2.1 


M 


M 


N/A 


Registration mode automatic access 


7.10.1.3.1 


M 


N/A 


N/A 


Base station limited registration mode 


7.10.1.2.2 


N/A 


M 


N/A 


Searching mode request 


7.10.1.2.3 


M 


N/A 


N/A 


Base station name selection 


7.10.1.3.2 








N/A 


Registration user feedback 


7.10.1.3.3 


M 





N/A 


NG1.A.3 Handset locator 




5.7 


M 








Handset locator 


7.10.2 


M 


M 





GAP.A.1 AG to bitstring mapping 




4.3 [11] 


M 


C1201 


M 


AG to bitstring mapping 


14.2 [11] 


M 


M 


M 


GAP.A.2 Multiple subscription 
registration 




4.3 [11] 


M 


N/A 


N/A 


Subscription control 


14.1 [11] 


M 


N/A 


N/A 


GAP.A.3 Manual entry of the 
PARK 




4.3 [11] 





N/A 


N/A 


Manual entry of the PARK 


14.3 [11] 


M 


N/A 


N/A 


GAP. A. 4 Terminal identity number 
assignment in mono cell system 




4.3 [11] 








N/A 


Terminal identity number assignment 


14.4 [11] 


M 


M 


N/A 


01201; IF feature GAP. N.9 OR 


GAP.N.10 OR GAP.N.12 OR GAP.N.26 Th 


lEN M ELSE 


N/A. 
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Annex G (informative): 

DTAIVI service use case examples 

G.1 Voice oriented remote DTAIVI with a DTAM number 



G.1 .1 DTAM incoming messages management 

In the case of a voice oriented DTAM, DTAM commands used for managing DTAM incoming messages do not require 
a message index (see clause 7.4.36.2.1). Therefore, no LiA session is used here. DTAM commands may be issued as 
soon as the call is placed. 

In this example, the PP (or PP user) relies on the DTAM Settings List to provide the DTAM number required in order to 
call the voice oriented DTAM. 



See the example in figure G.1 below. 
PP 



FP 



{CC-SETUP} 



« BASIC SERVICE, 

<basic service = 'DTAM wideband speecli default setup attributes'|> 

<call class = 'Normal call setup' > 
» 

{CC-CONNECT} 



« CALL-INFORMATION, call id=3» 
{CC-INFO} 



: CALL-INFORMATION, call id=3, call status = 'CS call setup ack' ; 



Voice oriented DTAIVI with a number 

{CC-INFO} 



« MULTI-KEYPAD, < Keypad info = '0' > » 

« CALL-INFORMATION, call id=3, line id=one of the DTAM line ids 



{CC-INFO} 



« CALL-INFORMATION, call id=3, call status = 'CS call proc' » 
{CC-INFO} 



« CALL-INFORMATION, call id=3, call status = 'CS call alerting' >; 
{CC-INFO} 



« CALL-INFORMATION, call id=3, call status = 'CS call connect' > . 
{IWU-to-IWU} 



« Start DTAM session <Line id> » 
{IWU-to-IWU} 



« Start DTAM session confirm » 
DTAM commands 



Store call in call table 
and assign call id 



Early CC-CONNECT 
message used: 
CS call connect call status 
not yet reached 



FP retrieves DTAM 
number from the DTAM 
settings list and start 
outgoing call towards 
remote DTAM 



network message 
'peer party is alerting' 



network message 
'peer party is active' 



Included DTAM session 
is started 

For use of DTAM 
commands 



Figure G.1 : Voice oriented remote DTAIU! (withi a DTAIU! number) 
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G.1.2 Welcome messages management 

Even for Voice oriented DTAMs, management of welcome messages are handled through a list. 
See the example in figure G.2 below. 

PP FP 

{CC-SETUP} 



« BASIC SERVICE, 

<basic service = 'DTAM wideband speech default setup attributes 

<call class = 'Normal call setup' > 
» 

{CC-CONNECT} 



« CALL-INFORIVIATION, call id=3» 
{CC-INFO} 



« CALL-INFORIVIATION, call id=3, call status = 'CS call setup ack' 



Voice oriented DTAIVI with a number 

{CC-INFO} 



« MULTI-KEYPAD, < Keypad info = '0' > » 

« CALL-INFORIVIATION, call id=3, one of the DTAIVI line ids » 



{CC-INFO} 



« CALL-INFORMATION, call id=3, call status = 'CS call proc' » 
{CC-INFO} 



« CALL-INFORMATION, call id=3, call status = 'CS call alerting' >; 
{CC-INFO} 



« CALL-INFORMATION, call id=3, call status = 'CS call connect' > > 



{IWU-to-IWU} 



« Start DTAM session <Line id> » 
{IWU-to-IWU} 



« Start DTAM session confirm : 

For any DTAIVI (Voice oriented or Visual) 
{IWU-to-IWU} 



Start LIA session <DTAM welcome message list> » 
{IWU-to-IWU} 



« Start LiA session confirm » 
DTAM welcome messages list retrieval for 
welcome management 



DTAM commands 



Store call in call table 
and assign call id 



Early CC-CONNECT 
message used: 
CS call connect call status 
not yet reached 



start outgoing call 
towards remote DTAM 



network message 
'peer party is alerting' 



network message 
'peer party is active' 



Included DTAM session 
is started 

For use of DTAM 
commands 



For visual 
management of 
welcome messages 

and retrieval of 
message indices 
used in DTAM 
commands 



Figure G.2: Voice oriented remote DTAIVI (with a DTAIVI number) 



£75/ 



198 ETSI TS 102 527-5 V1.1.1 (2013-04) 



G.2 Local or remote (visual) DTAM without DTAM 
number 

G.2.1 DTAM incoming/Welcome messages management 

Even when no 'DTAM number' is defined for a DTAM, an empty keypad information is sent to the FP. The 'Cs call 
proc' call status is sent back to inform the PP that no more information is needed in order to reach the DTAM. 

See the example in figure G.3 below. 
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PP 



FP 



{CC-SETUP} 



« BASIC SERVICE, 

<basic service = 'DTAM wideband speech default setup attributes' 

<call class = 'Normal call setup' > 
» 

{CC-CONNECT} 



« CALL-INFORIVIATION, call id=3» 
{CC-INFO} 



« CALL-INFORMATION, call id=3, call status = 'CS call setup ack' 

DTAM with no DTAM number 

{CC-INFO} 



« MULTI-KEYPAD, < Keypad info = '0' > » 

« CALL-INFORMATION, call id=3, one of the DTAM line ids » 



{CC-INFO} 



« CALL-INFORMATION, call id=3, call status = 'CS call proc' » 
{CC-INFO} 



« CALL-INFORMATION, call id=3, call status = 'CS call alerting' >; 
{CC-INFO} 



« CALL-INFORMATION, call id=3, call status = 'CS call connect' 
{IWU-to-IWU} 



« Start DTAM session <Line id> » 
{IWU-to-IWU} 



« Start DTAM session confirm » 

Especially for a Visual DTAM 

{IWU-to-IWU} 

« Start LIA session <DTAM incoming call list> » 
{IWU-to-IWU} 



« Start LIA session confirm » 
DTAM incoming call list retrieval for messages management 

DTAM commands 

For any DTAM (Voice oriented or Visual) 
{IWU-to-IWU} 



Start LIA session <DTAM welcome message list> » 
{IWU-to-IWU} 



« Start LiA session confirm » 
DTAM welcome messages list retrieval for 
welcome management 

DTAM commands 



Store call in call table 
and assign call id 



Early CC-CONNECT 
message used: 
CS call connect call status 
not yet reached 



start outgoing call 
towards remote DTAM 



network message 
'peer party is alerting' 



network message 
'peer party is active' 



Included DTAM session 
is started 

For use of DTAM 
commands 

For visual 
management of 
incoming messages 

and retrieval of 
message indices 
used in DTAM 
commands 



For visual 
management of 
welcome messages 

and retrieval of 
message indices 
used in DTAM 
commands 



Figure G.3: Local or remote visual DTAM without a number 
Start session/DTAM id used as a replacement for the keypad info 



G.3 DTAM message deletion via Delete entry 

No DTAM consulting call (and DTAM session) is strictly necessary for deleting a message. However the following use 
case should not be used for DTAMs having a number. 

See the example in figure G.4 below. 
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PP 



FP 



{CC-SETUP} 



« BASIC SERVICE, 
<basic service = 'Wideband speech default setup attributes'> 
<call class = 'LiA service call' > » 

{CC-CALL-PROCI 



NO «CALL-INFORMATION» here, because 

no call Id is used for a list access service call 
no 'CS call proc' call status either 



Retrieval of DTAM incoming call list 



{IWU-tO-IWU} 



« Start LiA session <DTAM incoming call list> » 
{IWU-to-IWU} 



« Start (LiA) session confirm total number=5» 
{IWU-to-IWU} 



« Read entries start index=1 , direction=forward, counter=5 » 
{IWU-to-IWU} 



« Read entries confirm » 
{IWU-to-IWU} 



« data packet including in particular entry id 125 data» 
{IWU-to-IWU} 



« data packet last » 



{IWU-to-IWU} 



« Delete entry entry id=125 » 
{IWU-to-IWU} 



: Delete entry confirm 



Service call: 
No call id used 



No CC-SETUP-ACK 



IVIessage deleted in 
the DTAIVI as if 
'Delete message' 
DTAM command 
had been used 



Figure G.4: DTAM message deletion without a DTAM consulting call 
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Annex H (normative): 
Editable fields 



All mandatory requirements as defined in Annex H of TS 102 527-3 [18] shall apply with the following additions in 
tables H.ll, H.12, H.13, H.14 and H.15 below. 

Table H.11 : 'Editable' status in the "SMS Settings List" 



Field id 


Field 


Clause 


Editable 


01H 


SMS service id 


7.4.35.4.2.1 


NO 


02H 


Line id 


7.4.10.5.1.7 


YES 


03H 


Enable SMS 


7.4.35.4.2.2 


MD 


04H 


Max SMS size 


7.4.35.4.2.3 


MD 


05H 


SMSC Send Server 


7.4.35.4.2.4 


MD 


06H 


SMSC Receive Server 


7.4.35.4.2.5 


MD 


07H 


SMS delivery report 


7.4.35.4.2.6 


YES 


08H 


SMS validity period 


7.4.35.4.2.7 


YES 


09H 


Allowed SMS character encodings 
and variants 


7.4.35.4.2.8 


NO 



Table H.12: 'Editable' status in the "Incoming SMS List" 



Field 
identifier 


Field 


Clause 


Editable 


01H 


Number 


7.4.10.5.1.2 


NO 


02H 


Name 


7.4.10.5.1.3 


NO 


03H 


Date and Time 


7.4.10.5.1.4 


NO 


04H 


Read status 


7.4.10.5.1.5 

and 

7.4.35.5.1.4 


YES 


05H 


SMS service id 


7.4.35.4.2.1 


NO 


06H 


SMS size 


7.4.35.5.1.2 


NO 


07H 


SMS content 


7.4.35.5.1.3 


NO 



Table H.13: 'Editable' status in the "Sent SMS List" 



Field 
identifier 


Field 


Clause 


Editable 


01H 


Number 


7.4.10.5.1.2 


NO 


02H 


Name 


7.4.10.5.1.3 


NO 


03H 


Date and Time 


7.4.10.5.1.4 


NO 


04H 


SMS service id 


7.4.35.4.2.1 


NO 


05H 


Network side SMS 
encoding 


7.4.35.5.1.1 


NO 


06H 


SMS size 


7.4.35.5.1.2 


NO 


07H 


SMS content 


7.4.35.5.1.3 


NO 
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Table H.14: 'Editable' status In the "Outgoing SMS List" 



Field 
identifier 


Field 


Clause 


Editable 
(note) 


01H 


Number 


7.4.10.5.1.2 


YES 


02H 


Name 


7.4.10.5.1.3 


YES 


03H 


Date and Time 


7.4.10.5.1.4 


YES 


04H 


SIVIS service id 


7.4.35.4.2.1 


YES 


05H 


Network side SIVIS 
encoding 


7.4.35.5.1.1 


YES 


06H 


SIVIS size 


7.4.35.5.1.2 


YES 


07H 


SIVIS content 


7.4.35.5.1.3 


YES 


NOTE: Editability is necessary at least at entry creation using 
save(O) (see clause 7.4.10.4.5.1, Procedure not 
allowed). However further attempts to modify the entry 
is likely to trigger a FP negative acknowledgement 
(already at 'edit entry' stage) if the FP is already 
attempting to send the SIVIS to the network. 



Table H.15: 'Editable' status in tlie "Draft SIVIS List" 



Field 
identifier 


Field 


Clause 


Editable 


01H 


Number 


7.4.10.5.1.2 


YES 


02H 


Name 


7.4.10.5.1.3 


YES 


03H 


Date and Time 


7.4.10.5.1.4 


NO 


04H 


SIVIS service id 


7.4.35.4.2.1 


YES 


05H 


Sending request 


7.4.35.5.1.5 


YES 


06H 


Network side SMS 
encoding 


7.4.35.5.1.1 


YES 


07H 


SIVIS size 


7.4.35.5.1.2 


YES 


08H 


SIVIS content 


7.4.35.5.1.3 


YES 
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